From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25961 invoked by alias); 4 Dec 2013 19:36:00 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 25938 invoked by uid 48); 4 Dec 2013 19:36:00 -0000 From: "dje at google dot com" To: gdb-prs@sourceware.org Subject: [Bug server/16168] Signal heavy execution + repeated breakpoint locks up gbserver Date: Wed, 04 Dec 2013 19:36:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: server X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dje at google dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-q4/txt/msg00509.txt.bz2 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.