This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Failure in tst-pthread-getattr.out.
- From: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: "Carlos O'Donell" <carlos_odonell at mentor dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 22 Jun 2012 04:04:20 -0400
- Subject: Re: Failure in tst-pthread-getattr.out.
- References: <4FE378DE.8050906@mentor.com> <20120622091436.01004c38@spoyarek>
On Thu, Jun 21, 2012 at 11:44 PM, Siddhesh Poyarekar
<siddhesh@redhat.com> wrote:
> On Thu, 21 Jun 2012 15:41:18 -0400, Carlos wrote:
>> Test output file:
>> ~~~
>> Verifying that stack top is accessible
>> Adjusting RLIMIT_STACK to 93554184359937
>> Adjusted rlimit: stacksize=93554184355840, stackaddr=0x2ae95be09000
>> ~~~
>>
>
> That is a massive value for rlimit. That can either be returned by the
> kernel or incorrectly computed by pthread_getattr_np.
>
> pthread_getattr_np returns min(rlimit_stack, distance to previous vma).
> Since the test case is single-threaded and the pthread_getattr_np code
> is pretty straightforward, a race condition within this is unlikely.
> The changes I have made only make the returned value smaller if
> anything, so that couldn't have caused a too-large stacksize.
>
> If the default rlimit for the application was set too high or was
> unlimited, the problem would have occurred all the time, so that is not
> possible either.
>
> So this looks to me like a case where the kernel has barfed out an
> excessively high value due to some obscure race condition. That or some
> obscure shell/make bug, which fails to pass on the right rlimits
> sometimes. Have I missed any other possibility? Maybe I'll get some more
> clues if you get a core dump and the binary along with test case output
> the next time the test fails.
If this is kernel issue, i'd like to fix it.
Carlos, Can you please show us your "ulimit -a" command output? I'm not
familiar Ubuntu default value.