Re: [PATCH]: linux and zombie threads

[Michael Snyder <msnyder@redhat.com>]

Mark Kettenis wrote:
> 
> Michael Snyder <msnyder@cygnus.com> writes:
> 
> > Mark -- these changes prepare the way for a libthread_db change
> > that will allow gdb to recognize zombie threads.
> 
> Hmm, what do you mean with zombie threads when you're talking about a
> libthread_db change?
> 
> For clarity, it seems to be two concepts of "zombie" related to
> LinuxThreads.  One is which I would call a "zombie thread", which
> basically is a thread that has exited (by invoking pthread_exit() or
> returning from the, but has not yet been joined.  These are reported
> by libthread_db as TD_THR_ZOMBIE.

Yes.

> The other I would call a "zombie process", which basically is a kernel
> thread that has exited (by invoking _exit()) but has not yet been
> waited for.  These are the ondes reported as TD_THR_UNKNOWN.  Their
> existence is very Linux-specific, and the fact that they tend to show
> up when debugging is related to a kernel bug for which I have been
> unable to find a kernel hacker to fix.

These also show up when a thread has exited and has been
pthread_joined.  I'm sure it's a kernel bug, but without 
these changes, it gets GDB all screwed up.

> 
> > 2001-05-22  Michael Snyder  <msnyder@redhat.com>
> >
> >       * thread-db.c: Allow for defunct zombie threads.
> >       (attach_thread): Do not attempt to attach zombie thread.
> >       (thread_db_thread_alive): Return false for defunct zombie thread.
> >       (find_new_threads_callback): Don't add defunct zombie thread to list.
> 
> That said, I think your patch is OK.  We want GDB to ignore the
> "zombie processes".  Practically all Linux kernels contain the bug
> that creates them, and even if the bug was fixed, there probably is a
> small window where these "zombie processes" are visible.
> 
> Could you clean up your patch a bit before checking it in?  There seem
> to be some whitespace/indentation problems.  And lining up the local
> variables in thread_db_thread_alive() seems to be against the coding
> standards too (since it introduces unnecessary whitespace).
> 
> Mark