This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix false positives in tst-pthread-getattr test case


On 6/26/2012 3:28 AM, Siddhesh Poyarekar wrote:
> Hi,
> 
> Here's a patch that fixes the test case to remove the false-positives
> most of us were getting in the result. Like I said in an earlier
> thread, it does not mean that the bug has not been fixed -- just that
> the test case was wrong.
> 
> In some cases, the compiler would optimize out the call to
> allocate_and_test and thus result in a false positive for the test
> case. Another problem was the fact that the compiler could move the
> stack pointer beyond what we expect, resulting in the alloca call moving
> the stack pointer beyond what is allowed by the rlimit. Hence,
> accessing the stackaddr returned by pthread_getattr_np is safer than
> relying on the alloca'd result.
> 
> The problem that Carlos reported still remains. I have seen this crash
> occasionally after fixing the above and here's what is happening in my
> case:
> 
> * The rlim_cur is returned as unlimited (-1)
> * The test case sets the rlimit to the distance to the previous vma,
>   which is quite large
> * Since most systems are set with vm.overcommit_memory sysctl set to 0
>   (heuristic overcommit), the heuristic fails for such a large value
>   and hence results in a segfault.
> 
> Setting vm.overcommit_memory to 1 (always overcommit) fixes this crash.
> 
> As for where RLIMIT_STACK is being set as unlimited, it is definitely
> not anything within glibc. The kernel, shell or make may be to blame
> for it, the kernel being the most likely culprit.
> 
> Regards,
> Siddhesh
> 
> nptl/ChangeLog:
> 
> 2012-06-26  Siddhesh poyarekar  <siddhesh@redhat.com>
> 
> 	[BZ #12416]
> 	* tst-pthread-getattr.c (allocate_and_test): Return STACKADDR.
> 	Access STACKADDR instead of MEM to test.
> 	(check_stack_top): Read valued written into STACKADDR in
> 	allocate_and_test.
> 

This looks good to me for 2.17 when it opens.

Thanks for working this out.

It really seems like it's our fault for setting the rlimit to something so big?

The kernel doesn't have much choice but to kill the program?

What other behavior is sensible?

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]