Re: Linux threads support in GDB

[gdb at dontknow dot org]

On 02-Oct-00 Mark Kettenis wrote:
>    Date: Wed, 13 Sep 2000 18:25:21 -0600 (MDT)
>    From: gdb@dontknow.org
> 
> Appologies for the this late reply.  Meanwhile, the particular failing
> assertions you were seeing should be gone.

I actually tested it, and it gets rid of the assertion, though the application
still exits when the SIGALRM happens while the processes is STOP'ed. Is there
any way to queue up the signals and send them upon program/thread resumption?

I did however realize that part of what I was missing about the problem is
that all threads are stopped during program breakpoints. So I guess that I can
kinda see how signals happening while the program is stopped. Can the itimer be
suspended somehow when trying to stop all threads? (Yes I know, timers are only
one possible cause, and finding all causes would be impossible since user
applications could cause the problem, however itimer might be the most common.
And something special must be happening for SIGUSR1 which pthread uses, but I
haven't looked at too many of the GDB threading internals.)

>    Ok, here is a test case that will reproduce the problem (to some
>    extent anyways). I guess for some of my testing trying to reproduce
>    the problem with something similiar I was using GDB 5.0, not the
>    cvs version. However that version also has problems with the
>    following code.) Normally when I run the real application I have
>    SIGSTOP and SIGCONT set to nostop, which may be why it isn't seen
>    until a breakpoint is used, whereas here it happens after the
>    implicit SIGCONT breakpoint.
> 
> Hmm.  GDB heavily relies on SIGSTOP itself.  There is no other way to
> stop threads in Linux :-(.  Due to the nature of signals (particularly
> the fact that multiple signals might be merged into one), this rather
> hoplessly interferes with the SIGSTOPs you're using in your program.
> I really don't intend to fix this.  Sorry.
> 
> Mark
> 
> PS Please keep CC'ing the GDB mailing list.  These discussions could
> be useful for other people too.



Contrary to popular belief, UNIX is user friendly.
  It just happens to be selective about who it makes friends with.