From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BE12C3858C3A; Thu, 1 Dec 2022 15:07:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE12C3858C3A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1669907240; bh=vEuGCHDjL9gkz8Fa+u6PpCJhF1vwj3zoBC0ukhIksCs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fmlcK1ppVANrlvKcCKkbyai+rd5BfdK4U26kdftCdauLW5poktTFkklBTojmMjah2 m7GcL/O31Y/oLPeDdEeGmSlN6B9hZFQD9YujUEKsAfoz03M43yIPPz4o3bkaEKO3wj irK7tLCMMUZXL9E7qPAjDdRnj4ezfSKzIJuexsX0= From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug gdb/28275] commit_resumed_state assertion failure when killing running inferior and running again Date: Thu, 01 Dec 2022 15:07:19 +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: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 13.1 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D28275 --- Comment #15 from cvs-commit at gcc dot gnu.org --- The gdb-12-branch branch has been updated by Simon Marchi : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D0fd7bbc90133= 138d12914608ebb68bab16259b78 commit 0fd7bbc90133138d12914608ebb68bab16259b78 Author: Andrew Burgess Date: Mon Nov 21 12:12:11 2022 -0500 gdb: fix assert when quitting GDB while a thread is stepping This commit addresses one of the issues identified in PR gdb/28275. Bug gdb/28275 identifies a number of situations in which this assert: Assertion `!proc_target->commit_resumed_state' failed. could be triggered. There's actually a number of similar places where this assert is found in GDB, the two of interest in gdb/28275 are in target_wait and target_stop. In one of the comments: https://sourceware.org/bugzilla/show_bug.cgi?id=3D28275#c1 steps to trigger the assertion within target_stop were identified when using a modified version of the gdb.threads/detach-step-over.exp test script. In the gdb.threads/detach-step-over.exp test, we attach to a multi-threaded inferior, and continue the inferior in asynchronous (background) mode. Each thread is continuously hitting a conditional breakpoint where the condition is always false. While the inferior is running we detach. The goal is that we detach while GDB is performing a step-over for the conditional breakpoint in at least one thread. While detaching, if a step-over is in progress, then GDB has to complete the step over before we can detach. This involves calling target_stop and target_wait (see prepare_for_detach). As far as gdb/28275 is concerned, the interesting part here, is the the process_stratum_target::commit_resumed_state variable must be false when target_stop and target_wait are called. This is currently ensured because, in detach_command (infrun.c), we create an instance of scoped_disable_commit_resumed, this ensures that when target_detach is called, ::commit_resumed_state will be false. The modification to the test that I propose here, and which exposed the bug, is that, instead of using "detach" to detach from the inferior, we instead use "quit". Quitting GDB after attaching to an inferior will cause GDB to first detach, and then exit. When we quit GDB we end up calling target_detach via a different code path, the stack looks like: #0 target_detach #1 kill_or_detach #2 quit_force #3 quit_command Along this path there is no scoped_disable_commit_resumed created. ::commit_resumed_state can be true when we reach prepare_for_detach, which calls target_wait and target_stop, so the assertion will trigger. In this commit, I propose fixing this by adding the creation of a scoped_disable_commit_resumed into target_detach. This will ensure that ::commit_resumed_state is false when calling prepare_for_detach from within target_detach. I did consider placing the scoped_disable_commit_resumed in prepare_for_detach, however, placing it in target_detach ensures that the target's commit_resumed_state flag is left to false if the detached inferior was the last one for that target. It's the same rationale as for patch "gdb: disable commit resumed in target_kill" that comes later in this series, but for detach instead of kill. detach_command still includes a scoped_disable_commit_resumed too, but I think it is still relevant to cover the resumption at the end of the function. Co-Authored-By: Simon Marchi Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D28275 Change-Id: Ie128f7aba6ef0e018859275eca372e6ea738e96f --=20 You are receiving this mail because: You are on the CC list for the bug.=