Re: RFC: Re: [patch] Fix for 'info threads' crashes if zombie threads exist

[Jan Kratochvil <lace at jankratochvil dot net>]

Hi Daniel,

On Tue, 20 Jun 2006 19:11:09 +0200, Daniel Jacobowitz wrote:
...
> TD_DEATH events were supported because there are all sorts of things
> which can go wrong when you ask libthread_db about a thread that it
> considers dead.  At that point, as far as the library is concerned, the
> thread is gone.
> After your patch, I strongly suspect there are places where you could hit
> control-c and get mysterious errors from GDB.

OK...  I checked now that my patch may have problems accessing TCB after:
	if (IS_DETACHED (pd)) __free_tcb (pd);
for the detached threads and it even has problems before this point (not
analysed why):
	Program received signal SIGTRAP, Trace/breakpoint trap.
	[Switching to Thread -1208153184 (unknown thread_db state 1)]
	0x00000000 in ?? ()

Proposing the attached reduced patch with only the most important+safe part.
It still catches the initial terminating state with EXITING_BIT
(->TD_THR_ZOMBIE) where I hope most of the crashes/breakpoints may occur.

Still the perfect functionality would require patching libthread_db and it
looks to me a bit as a chicken&egg problem. :-)


> A new thread can be created with the same thread ID - even before this one
> exits.

Not sure of how much are non-Linux platforms a concern for these minor issues.
Apparently on Linux kernel the same LWP id cannot be created until the final
syscall __NR_exit.


Regards,
Jan Kratochvil


> A little patience, please.  It takes a while to review GDB patches,
> especially non-obvious ones - and thread-db support seems to be quite
> complicated.

(Sorry, I only did not want to get the patch lost.)

Attachment: gdb-cvs20060620-pthread_exit.patch
Description: Text document