From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EDC703858C27; Fri, 4 Mar 2022 11:15:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EDC703858C27 From: "aburgess at redhat dot com" 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 11:15:27 +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: aburgess at redhat dot com 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: bug_status cc cf_reconfirmed_on everconfirmed 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 11:15:28 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28942 Andrew Burgess changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |aburgess at redhat dot com Last reconfirmed| |2022-03-04 Ever confirmed|0 |1 --- Comment #1 from Andrew Burgess --- Wow, it's a small world. I literally just started looking at this same is= sue this week. The whole thread not marked resumed issue is fixed by this excellent patch: https://sourceware.org/pipermail/gdb-patches/2022-January/185109.html Which you know as you already posted a link to this bug to that thread. However, there are so many other problem related to this issue. The first thing I noticed is that run_inferior_call calls clear_proceed_sta= tus, which in all-stop mode calls clear_proceed_status_thread for each thread. 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. Currently the not-executing assert will fail, but (due to the above patch b= eing missing) the not-resumed assert will only fail sometimes. 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 res= umed threads as part of the inferior call. However, after the call, as we're in all-stop mode, GDB will stop all threa= ds. However, if the breakpoint condition doesn't segfault, but instead just ret= urns false, then GDB will resume the single thread that stopped for the breakpoi= nt - leaving all the other threads stopped. 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 that, 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 mo= re testing yet - maybe this is a really bad idea. The only other option I can think of is to somehow have the infcall code fi= gure out that we are in all-stop mode, but some threads are already running. Th= en, after making the inferior call we only stop the set of threads that we star= ted. However, this has a massive problem; how to handle new threads? 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=