From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 899193858419; Fri, 4 Mar 2022 14:44:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 899193858419 From: "simark at simark dot ca" To: gdb-prs@sourceware.org Subject: [Bug gdb/28942] Problem with breakpoint condition calling a function in multi-threaded program Date: Fri, 04 Mar 2022 14:44:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: simark at simark dot ca X-Bugzilla-Status: NEW X-Bugzilla-Resolution: 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: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2022 14:44:08 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28942 Simon Marchi changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simark at simark dot ca --- Comment #3 from Simon Marchi --- (In reply to Andrew Burgess from comment #1) > Wow, it's a small world. I literally just started looking at this same > issue this week. >=20 > The whole thread not marked resumed issue is fixed by this excellent patc= h: >=20 > https://sourceware.org/pipermail/gdb-patches/2022-January/185109.html >=20 > Which you know as you already posted a link to this bug to that thread. >=20 > However, there are so many other problem related to this issue. >=20 > The first thing I noticed is that run_inferior_call calls > clear_proceed_status, which in all-stop mode calls > clear_proceed_status_thread for each thread. >=20 > Once the above patch is merged I plan to add an assert to > clear_proceed_status_thread that the thread we are clearing is not resumed > and not executing. >=20 > Currently the not-executing assert will fail, but (due to the above patch > being missing) the not-resumed assert will only fail sometimes. >=20 > If we ignore the clear_proceed_status issue, then with the above patch the > resumed flag will be correct, and GDB will not try to start the already > resumed threads as part of the inferior call. >=20 > However, after the call, as we're in all-stop mode, GDB will stop all > threads. >=20 > However, if the breakpoint condition doesn't segfault, but instead just > returns false, then GDB will resume the single thread that stopped for the > breakpoint - leaving all the other threads stopped. Yeah, the fact that the breakpoint condition function caused a segfault is = just another difficulty on top. You can ignore that part. > I'm currently working on the idea that when we evaluate the breakpoint > condition we temporarily place GDB into non-stop mode, this would mean th= at, > when we evaluate the b/p condition we only restart the one thread, and > afterwards, we only expect the one thread to stop, but I need to do lots > more testing yet - maybe this is a really bad idea. >=20 > The only other option I can think of is to somehow have the infcall code > figure out that we are in all-stop mode, but some threads are already > running. Then, after making the inferior call we only stop the set of > threads that we started. However, this has a massive problem; how to han= dle > new threads? When thinking about this, my intuition was more like the later. In all-stop over a non-stop target: 1. A thread hits a breakpoint, only that thread is stopped while we process= the breakpoint hit 2. When doing the infcall in the breakpoint condition, only that thread is resumed (the other threads already are) 3. When the infcall is done, only that thread is stopped 4a. If the condition is true, then GDB stops all threads 4b. if the condition is false, that thread is resumed In all-stop over an all-stop target: 1. A thread hits a breakpoint, all threads are stopped while we process the breakpoint hit 2. When doing the infcall in the breakpoint condition, all threads are resu= med (is this what would happen if the user were to do a manual infcall?) 3. When the infcall is done, all threads are stopped 4a. If the condition is true, all threads remain stopped 4b. If the condition is false, all threads are resumed In non-stop over a non-stop target, then it looks like "all-stop-on-top-of-non-stop", except that not all threads are stopped in s= tep 4a. I didn't really think through what would happen to new threads, I suppose t= hey would just keep running. >=20 > I'll clean up my correct patch and post it to this bug later today in case > anyone wants to try it. I'll also add your crashing function test to my > working branch to make sure that is handled too. Thanks, that's some really quick customer service. --=20 You are receiving this mail because: You are on the CC list for the bug.=