[RFA] lin-lwp.c change to avoid obscure hanging
Paul N. Hilfinger
hilfingr@otisco.mckusick.com
Wed Apr 17 02:52:00 GMT 2002
> > 3. The user executes the commands
> > delete
> > thread B
> > continue
> This isn't really a sensable thing to do anyway.
> Probably the user is imagining that this will cause
> thread B to be treated in some way specially (eg.
> resumed before the others), but it will not
> (or at least it should not).
Oh, I'm SO glad you brought this up, because it is a point that could stand
clarification.
Q1. Consider the following sequence (user input preceded by prompts)
(gdb) run
...
Breakpoint 1, philosopher ...
(gdb) info thread
* 7 Thread 5126 (runnable) ...
...
(gdb) thread 6 # I.e., Some thread other than the current one
(gdb) signal 1
What is supposed to happen? What DOES happen (on Linux) is that thread 7
receives SIGHUP.
Q2. Now consider what happens when one thread is sent an asynchronous SIGHUP
(on Linux, there are kernel threads, and you can address a signal to
a specific thread from the command line with the kill command).
(gdb) run
...
Program received signal SIGHUP, Hangup.
...
(gdb) info thread
* 7 Thread 5126 (runnable) ...
...
(gdb) thread 6
(gdb) cont
Here what happens is that thread *6* receives SIGHUP.
Q3. Finally, we have
(gdb) run
...
Program received signal SIGHUP, Hangup.
...
(gdb) info thread
* 7 Thread 5126 (runnable) ...
...
(gdb) thread 6
(gdb) signal 1
Again, thread 6 receives SIGHUP.
Question: How much of this, if any, is intentional? What should happen in
these cases?
Paul Hilfinger
More information about the Gdb-patches
mailing list