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: Failure in tst-pthread-getattr.out.


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.

BTW, I am assuming all along that the make check run is with a fresh
build. I personally can't see any way in which an incremental build will
cause problems here though.


Regards,
Siddhesh


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