[Bug server/16168] Signal heavy execution + repeated breakpoint locks up gbserver

["dje at google dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16168

dje at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at google dot com

--- Comment #2 from dje at google dot com ---
What happens here is this:

1) This is all-stop, SIGPROF is active, and a thread hits a breakpoint.
gdbserver stops all threads, and while stopping all threads one thread gets a
SIGPROF.

2) gdb then advances the breakpointed thread passed the breakpoint and then
resumes all threads.

3) gdbserver gets the resume request and looks for a thread with a pending
signal, finds it (the SIGPROF'd thread), and leaves all threads stopped knowing
linux_wait_for_event will find the thread with status_pending_p (there could be
more than one of course).

4) gdbserver then enters wait processing for all threads, linux_wait_for_thread
finds the SIGPROF'd thread which linux_wait_1 forwards on to the inferior, and
goes back to waiting for all threads.

5) At this point only the SIGPROF'd thread is running and linux_wait_1 is
waiting for an event worthy of reporting back to gdb.
gdbserver sees the SIGSTOP that was sent earlier to stop all threads, knows it
no longer cares about it, resumes the thread, and goes back to waiting for all
threads. The thread continues to receive SIGPROF which are continually
forwarded on and eventually the thread exits.

6) At this point gdbserver is hung waiting for an event from some thread, but
no threads are running.

>From a high level perspective, if we want to keep the "any_pending" processing,
a signal gdb doesn't care about is different than a signal gdb does care about,
and the "any_pending" processing that gdbserver does only applies to the
latter, not the former.  E.g., if there are 10 threads to be resumed, 1 of
which is a "normal" resume after a SIGSTOP, and 9 have different signals all
marked as "nostop noprint pass", then that is no different than having the same
10 threads all marked for "normal" resumption: resume them all in the way
appropriate for each thread.
Thus, from a high level perspective, IWBN to distinguish signals thusly. 
Whether that's actually easy/possible in the implementation ... have to see.

-- 
You are receiving this mail because:
You are on the CC list for the bug.