It was observed that in a multi-threaded application on GNU/Linux,
that if the user has set the SIGSTOP to be pass (using GDB's handle
command) then the inferior would hang upon hitting a breakpoint.
What happens is that when a thread hits the breakpoint GDB tries to
stop all of the other threads by sending them a SIGSTOP and setting
the stop_requested flag in the target_ops structure - this can be seen
in infrun.c:stop_all_threads.
GDB then waits for all of the other threads to stop.
When the SIGSTOP event arrives we eventually end up in
linux-nat.c:linux_nat_filter_event, which has the job of deciding if
the event we're looking at (the SIGSTOP arriving in this case) is
something that should be reported back to the core of GDB.
One of the final actions of this function is to check if we stopped
due to a signal, and if we did, and the signal has been set to 'pass'
by the user then we ignore the event and resume the thread.
This code already has some conditions in place that mean the event is
reported to GDB even if the signal is in the set of signals to be
passed to the inferior.
In this commit I extend this condition such that:
If the signal is a SIGSTOP, and the thread's stop_requested flag is
set (indicating we're waiting for the thread to stop with a SIGSTOP)
then we should report this SIGSTOP to GDB and not pass it to the
inferior.
With this change in place the test now passes. Regression tested on
x86-64 GNU/Linux with no regressions.
gdb/ChangeLog:
* linux-nat.c (linux_nat_filter_event): Don't ignore SIGSTOP if we
have just sent the thread a SIGSTOP and are waiting for it to
arrive.
gdb/testsuite/ChangeLog:
* gdb.threads/stop-with-handle.c: New file.
* gdb.threads/stop-with-handle.exp: New file.
