nptl/tst-eintr1.c test question
Florian Weimer
fweimer@redhat.com
Fri Dec 16 07:46:00 GMT 2016
On 12/16/2016 12:02 AM, Steve Ellcey wrote:
> FYI: The failure I get is due to to many forks causing the make process(es) to
> abort:
>
> ../scripts/evaluate-test.sh nptl/tst-eintr1 $? false false > /home/ubuntu/sellcey/glibc-patched/obj-glibc64/nptl/tst-eintr1.test-result
> /bin/sh: 2: Cannot fork
> ../Rules:241: recipe for target '/home/ubuntu/sellcey/glibc-patched/obj-glibc64/nptl/tst-eintr1.out' failed
> make[2]: *** [/home/ubuntu/sellcey/glibc-patched/obj-glibc64/nptl/tst-eintr1.out] Error 2
> make[2]: Leaving directory '/home/ubuntu/sellcey/glibc-patched/src/glibc/nptl'
> Makefile:215: recipe for target 'nptl/tests' failed
> make[1]: *** [nptl/tests] Error 2
> make[1]: Leaving directory '/home/ubuntu/sellcey/glibc-patched/src/glibc'
> Makefile:9: recipe for target 'check' failed
> make: *** [check] Error 2
So the failure happens outside of the test harness. This means we
cannot intercept it.
Some kernel developers have suggested we should just retry the fork if
we get EAGAIN (and do the same for thread creation). But I don't think
this is a good idea—we would either have to do it in glibc, or any shell
on the planet. It's also not clear how many attempts are are needed to
cover up the race.
A few more details are available here:
https://bugzilla.kernel.org/show_bug.cgi?id=154011
It may help to disable cgroups restrictions and avoid configuring low
per-user process limits. Or you might be observing a different issue,
not related to what we saw earlier this year on Fedora builders.
In the end, the kernel's fork/clone implementation is buggy and has to
be fixed.
Florian
More information about the Libc-alpha
mailing list