This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Thread exit & create events
> Date: Fri, 24 Aug 2007 10:51:10 +0200
> From: "Veenu Verma (AS/EAB)" <veenu.verma@ericsson.com>
>
> Hello
>
> We are integrating GDB back end with DSF ( Debugger Services Framework )
> in Eclipse.
> Found two stumbling blocks around thread exit/create events
>
> 1. Though GDB raises a thread exit event but -thread-list-ids command
> still list the reported exited thread for quite some time.
> There is a gap till I guess the thread completely exits. Only info
> threads give the hint by using "Exiting" in information.
> This is a problem for us as we are relying on events and thread-list-ids
> commands to paint the GUI.
> Info threads is used sparingly from front end.
> Can -thread-list-ids command take into account the exited threads ? Is
> it difficult to achieve this in GDB ?
GDB will defenitely need to keep track of the thread ID until the
thread is fully gone. I guess -thread-list-ids simply uses GDB's
internal thread list, so exiting thread show up. And I guess there
are people that actually want this, because the thread almost
certainly will still show up if you look for it with the tools your
operating system provides.
I guess the basic issue here is at what level you want to do thread
debugging. For debugging code that simply uses threads, you may want
to see the thread disappear if you call pthread_exit() (or whatever
function the threading library provides for terminating threads). But
if you have joinable threads you may want to keep them visible until
another thread has called pthread_join().
If you're debugging the threads library itself, you almost certainly
want to keep the thread visible until it has actually completely
stopped executing code.
> 2. GDB thread identifier is not speicified when a thread is created or
> exited. Only system identifier is used.
> Again thread-list-ids uses only gdb thread identifier. Hence, the
> mismatch and the problem.
> Since on HP-UX systems gdb thread identifier is shown, I'm guessing it
> shouldn't be hard to do the same for Linux.
> Is there a reason for not to have gdb identifier on linux or it's just
> that it's not done yet.
HP-UX has a rather well thought out debugging interface for threads.
That interface includes the possibility to store a thread identifier
in the kernel whenever a thread is created, and the debugger can ask
for that identifier. That makes it possible for GDB to always know
the thread identifier.
Linux doesn't have a very well thought out threads debugging
interface. There is special threads debugging library that is
supposed to help GDB find out things like userland thread identifiers,
but there are several versions of that library out there and some of
them have serious bugs. The workarounds we have for these bugs mean
that there always is a period of time where we are not completely sure
whether a thread is still alive or dead. During that time the thread
doesn't really have a valid thread identifier so it doesn't get
displayed. Something similar happens when creating a thread. When
the underlying kernel thread is created GDB notices that, but it
cannot yet ask the thread debugging library for the thread identifier,
since the data structures describing the thread haven't been set up
yet completely.