This is the mail archive of the
mailing list for the glibc project.
Re: NPTL not properly cleaning up threads on SMP systems?
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Thibaut Girka <thib at sitedethib dot com>
- Cc: libc-help at sourceware dot org
- Date: Sat, 2 Jun 2012 10:42:31 -0400
- Subject: Re: NPTL not properly cleaning up threads on SMP systems?
- References: <20120601203327.GA5223@debian-thib>
On Fri, Jun 1, 2012 at 4:33 PM, Thibaut Girka <firstname.lastname@example.org> wrote:
> I've recently tried to build eglibc from Debian's source package,
> but it aborted because of a failed test: 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
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?