This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
threads/1484: Sol9/x86 problem attaching to process with exited/unjoined thread
- From: trawick at attglobal dot net
- To: gdb-gnats at sources dot redhat dot com
- Date: 12 Dec 2003 20:37:54 -0000
- Subject: threads/1484: Sol9/x86 problem attaching to process with exited/unjoined thread
- Reply-to: trawick at attglobal dot net
>Number: 1484
>Category: threads
>Synopsis: Sol9/x86 problem attaching to process with exited/unjoined thread
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Dec 12 20:38:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: trawick@attglobal.net
>Release: 6.0
>Organization:
>Environment:
Solaris 9/x86 (08/03 refresh)
>Description:
Symptom:
attach to threaded program (a child process of apache httpd 2.0 with worker MPM), run "info threads", and receive this error:
55 Thread 2 procfs: couldn't find pid 3070 (kernel thread 2) in procinfo list.
Without "info threads" working, switching to any thread fails.
I guessed that this "thread 2" was a thread that was created with PTHREAD_CREATE_JOINABLE and has already exited (it won't be joined for some time). If I hack the application to have this thread block forever instead of exiting, I'm able to attach to the running process, complete "info threads" successfully, and get some work done.
FWIW, dbx on AIX displays such a thread as "(zombie)" in its equivalent of "info threads".
So problem seems to be inability to build list of threads if any of the threads are "zombies".
>How-To-Repeat:
an existing testcase is Apache 2 with worker MPM... start it, then try to attach to a threaded child process and run "info threads"
I can try to provide a simpler application to test with if desired.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: