NPTL not properly cleaning up threads on SMP systems?

[Carlos O'Donell]

On Fri, Jun 1, 2012 at 4:33 PM, Thibaut Girka <thib@sitedethib.com> wrote:
> I've recently tried to build eglibc from Debian's source package,
> but it aborted because of a failed test[1]: nptl/tst-eintr1.
> This test failed because one of the pthread_create calls returned EAGAIN.
> Indeed, after some time, instead of 12~23 threads,
> “grep Threads /proc/$PID/status” reveals much more threads (up to several thousands).
>
> I've attached a simpler testcase that triggers the same issue,
> which I have been able to reproduce using a freshly-built glibc from GIT.
>
> I haven't observed this issue on single-processor systems
> (ran the test on a dedicated user with a RLIMIT_NPROC of NB_THREADS + 3 for hours without getting EAGAIN).

This looks like you have a kernel bug.

On an x86-64 (X5560 4 core [8 hts], ~50GB RAM) system running Ubuntu
10.04.2 LTS 2.6.32-31-generic kernel I see 1-3 threads active at any
point.

In a perfectly synchronous world there would be only 1 thread active,
but I don't know what /proc/$PID/status(Threads) really represents
e.g. threads that are going to be reaped eventually?

Cheers,
Carlos.