This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Defunct threads on Alpha with linuxthreads
- From: Balint Cristian <cristian dot balint at oradea dot rdsnet dot ro>
- To: libc-alpha at sources dot redhat dot com,azarah at nosferatu dot za dot org
- Date: Fri, 16 Sep 2005 14:56:34 +0300
- Subject: Re: Defunct threads on Alpha with linuxthreads
- References: <1126867551.5006.40.camel@lycan.lan>
On Friday 16 September 2005 13:45, Martin Schlemmer wrote:
Anyway 2.3.90 aka pre 2.4.5 glibc will drop linuxthread, i think there are null interests for glibc
to fix this issue, nptl will remain only in the future.
> Hi,
> There already is a bug about this issue:
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=1297
> Basically with 2.4 or 2.6 kernels, glibc-2.3.[45] and linuxthreads,
> there are issues with cleaning up the threads, and you get a defunct
> process.
> ----- test case -----
> #include <pthread.h>
> #include <unistd.h>
> void myThread(void *foo) {
> pthread_exit(foo);
> }
> int main()
> {
> pthread_t tt;
> pthread_attr_t ta;
>
> pthread_attr_init(&ta);
> pthread_attr_setdetachstate(&ta, PTHREAD_CREATE_DETACHED);
>
> pthread_create(&tt, &ta, (void* (*) (void*))myThread, (void*)NULL);
>
> sleep(600);
>
> return 0;
> }
> -----
>
> Above code does the following:
>
> -----
> root 4541 0.0 0.1 4448 648 pts/0 S+ 01:32 0:00 /root/pthread-test
> root 4542 0.0 0.1 4448 648 pts/0 S+ 01:32 0:00 /root/pthread-test
> root 4543 0.0 0.0 0 0 pts/0 Z+ 01:32 0:00 [pthread-test] <defunct>
> -----
>
> And of course, pid 4543 is not debug-able. Adding a sleep and trying to
> debug the thread that goes defunct do not show this behaviour:
>
> -----
> Attaching to process 4525
> Using host libthread_db library "/lib/libthread_db.so.1".
> Reading symbols from /root/pthread-test...done.
> Reading symbols from /lib/libpthread.so.0...done.
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 4523)]
> [New Thread 32769 (LWP 4524)]
> [New Thread 16386 (LWP 4525)]
> Loaded symbols for /lib/libpthread.so.0
> Reading symbols from /lib/libc.so.6.1...done.
> Loaded symbols for /lib/libc.so.6.1
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> 0x00000200001734f4 in nanosleep () from /lib/libc.so.6.1
> (gdb) s
> Single stepping until exit from function nanosleep,
> which has no line number information.
> [Switching to Thread 16386 (LWP 4525)]
> pthread_handle_sigcancel (sig=524288) at descr.h:248
> 248 return THREAD_SELF;
> (gdb)
> 535 if (self == __manager_thread)
> (gdb)
> 1069 {
> (gdb)
> 248 return THREAD_SELF;
> (gdb)
> 1069 {
> (gdb)
> 248 return THREAD_SELF;
> (gdb)
> 1069 {
> (gdb)
> 535 if (self == __manager_thread)
> (gdb)
> 1073 if (self == manager_thread)
> (gdb)
> 1078 if (__builtin_expect (__pthread_exit_requested, 0)) {
> (gdb)
> 1081 if (self == __pthread_main_thread) {
> (gdb)
> 1088 _exit(__pthread_exit_code);
> (gdb)
> *__GI__exit (status=0) at _exit.c:35
> 35 INLINE_SYSCALL (exit, 1, status);
> (gdb)
>
> Program exited normally.
> (gdb)
> -----
>
> Debugging the manager thread seems to just loop inside
> __pthread_manager(). This issue is with both gcc-3.3.x and gcc-3.4.4, a
> few versions of binutils, and glibc-2.3.[45].
>
> NPTL works fine (and I know is the preferred threading implementation),
> but currently not entirely a solution, as some of the ev6 based boxes
> have issues with 2.6 kernels.
>
> Any ideas on how to proceed in debugging this will be appreciated.
>
>
> Regards,
>
--
Balint Cristian
area network engineer
.............................................................................
RCS & RDS Oradea
Tel.: +40359.400.400
Fax: +40359.400.444
http://www.rcs-rds.ro
suport@rdsor.ro
....................................................................................
Privileged/Confidential Information may be contained in this message.
If you are not in the addresses indicated in this message (or responsible
for delivery of the message to such person), you may not copy or deliver
this message to anyone. In such a case, you should destroy this
message and kindly notify the sender by reply e-mail.