Re: problems with gdb (specifically linuxthreads)

[Greg Galperin <grg22 at ai dot mit dot edu>]

Mark Kettenis wrote:
> As for the "many linuxthreads problems": would you please tell us what
> they are.  Apart from the spurious SIGTRAPs I'm not aware of any.

Well, for one there is the zombie problem I reported a couple weeks ago at

http://sourceware.cygnus.com/ml/bug-gdb/2000-02/msg00008.html

(Is the bug-gdb mailing list no longer used?  Nobody seemed to notice that
posting at all.)



I can probably act as a pretty good stress tester for x86 linux pthreads
code... I've never been able to run any gdb on the application I'm working
on (and would desperately like to).  I've tried 4.17, 4.18, HJ Lu's 4.17,
current dev branches from dec, jan, and feb; applied all the patches I can
find which seem at all relevant, have done some hacking myself, and none of
these actually let me debug my application.  (BTW, as noted in my other
email, this application does work, does have bugs, but runs for days
outside of gdb.)  I've also tried a glibc 2.1.3 in addition to my standard
2.1.2 with no difference noticed.  If you think you have a setup which
works for x86 linux pthreads, bring it on!!

In addition to the zombie problem described above, I've also run into the
signal trampoline problem, the SIGCHLD masking problem, and now I'm stuck
in the spurious SIGTRAP problem (recently rediscovered by Chris Blizzard,
below -- yes, I've seen it before :) .  I think the most recent gdb I've
tried was 20000206 (plus some patches and hacking on that one).



	===== Specific info about failure modes I've seen =====

Christopher Blizzard wrote:
> Program received signal SIGTRAP, Trace/breakpoint trap.
>...
> So, I've done some more digging into this and it looks like Jim Kingdon has
> reported this problem in the past:
> 
> http://sourceware.cygnus.com/ml/bug-gdb/1999-10/msg00058.html
> 
> I can reproduce this problem both with and without Tom's patch.  Has anyone
> seen this before?  Maybe have a solution for it hanging around? :)

Sorry, I haven't solved it yet; this one seems pretty tricky.

Extra info: when I get a spurious SIGTRAP (immediately, for the most part),
gdb picks as "current thread" one which has already pthread_exit()ed (but
hasn't fully cleaned up yet?? gdb shows it executing at a garbage
address..).  At that point I'm unable to continue running; gdb seems to
insist on trying to run that already-dead thread.  This seems to be related
to the spurious SIGTRAP but could possibly be a different issue?



Curiously, in some incarnations of gdb I've tried, after some amount of
screen output by the running program gdb suspends itself, complaining of
tty output, and then gives me its standard pager prompt when I fg it:

	Suspended (tty output)
	$ fg
	---Type <return> to continue, or q <return> to quit---

This happens in sessions where the only thing I do is "set args" and "run".
(Nothing too interesting in my .gdbinit either.)


Plus I have plenty of anecdotes like this about trying to debug this
linuxthreads app.  For instance, the one when gdb hangs until I hit ctrl-c,
at which point it silently resumes execution of the program.  Funky, eh?


Peace,
grg