This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Failure in tst-pthread-getattr.out.
On 6/22/2012 4:04 AM, KOSAKI Motohiro wrote:
> 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.
>
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) 8388608
open files (-n) 4096
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 1000
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
I've turned on core dumps so we'll see if I can catch it again.
Cheers,
Carlos.
--
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026