Re: nptl/tst-eintr1.c test question

[Florian Weimer <fweimer at redhat dot com>]

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