From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id C6063385BAF0 for ; Tue, 21 Nov 2023 16:11:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C6063385BAF0 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C6063385BAF0 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700583080; cv=none; b=aUVHaj0UAqJDVfeHF6mlHFlJ0vmhmH/tn2TRyLg9ci9lMrjiT+0JPemfIXwiYwEuU5Qgj7cShVooya0SNC+uQGQp207ecjvxPsXy3prUjMJDm/eeC35Q8+sx8YdoFZfwEyOk0prhWswi3tVI6+4qgvr9gI/xwjlm3Ob7C2VdXZc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700583080; c=relaxed/simple; bh=zfVH91fYKjbUMjLp5eiIU/ht2Whabm+7+aJTCE/sQV0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=qq69XdFhY2rbk3bo9m05+1TC8KpEMxTb0cizXtQyDbaXOErw/l7ERxvq41d5fh80f5Ehz6LegeQwJLWz16Ms4b4MjkFFGSGxZlRtvUmiOK/9/kvG1B9FonpFDx/pua6M2MiUtZB3fplD8YF9or0CDOdumfPGuq1UOPkBJlJmCeE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1700583077; bh=zfVH91fYKjbUMjLp5eiIU/ht2Whabm+7+aJTCE/sQV0=; h=Date:Subject:To:References:From:In-Reply-To:From; b=hluavy22mbqLGki7VCb5p0KFj42pZrbnRavbBcToswH7ElPuOirYV0kOyZCvQxvfH m8pMhGXOZxJ50rIO0+qBFy1B5TUcoE81js8NOkoxFVmGKlu3Dik8k7HFBzznK/yP7g kqPv2nOy0GhJ/G6BqHQv0dKc7HPRVwLouWMp+TAE= Received: from [172.16.0.192] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1A9A11E091; Tue, 21 Nov 2023 11:11:16 -0500 (EST) Message-ID: <114c9994-ed81-4a14-bcc3-bd8086e46340@simark.ca> Date: Tue, 21 Nov 2023 11:11:16 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] [gdb] Fix assert in delete_breakpoint Content-Language: fr To: Tom de Vries , gdb-patches@sourceware.org References: <20231113152609.32726-1-tdevries@suse.de> <601592c1-4e19-42c8-bfd7-5671ef951ab3@simark.ca> From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/15/23 06:12, Tom de Vries wrote: > Because it's deleted twice. > > The last thing we see in gdb.log before the internal error is: > ... > [infrun] handle_signal_stop: [13633.13633.0] hit its single-step breakpoint^M > ... > > And the statement following the infrun_debug_printf printing that message is: > ... > delete_just_stopped_threads_single_step_breakpoints (); > ... > > So, the following events happen: > - the single-step breakpoint is hit > - delete_just_stopped_threads_single_step_breakpoints is called > - during delete_just_stopped_threads_single_step_breakpoints, > delete_breakpoint is called which removes the breakpoint from the > breakpoint chain > - gdb is interrupted by SIGTERM before finish delete_breakpoint > - the SIGTERM triggers a SCOPE_EXIT cleanup, calling > delete_just_stopped_threads_infrun_breakpoints which ends up > calling delete_breakpoint again for the same breakpoint. > > The proposed fix tries to handle delete_breakpoint being interrupted, and called again. > > This is an alternative fix: > ... > diff --git a/gdb/thread.c b/gdb/thread.c > index 47cc5c9cd14..7f029f2414c 100644 > --- a/gdb/thread.c > +++ b/gdb/thread.c > @@ -93,11 +93,12 @@ inferior_thread (void) > static void > delete_thread_breakpoint (struct breakpoint **bp_p) > { > - if (*bp_p != NULL) > - { > - delete_breakpoint (*bp_p); > - *bp_p = NULL; > - } > + struct breakpoint *bp = *bp_p; > + > + *bp_p = nullptr; > + > + if (bp != nullptr) > + delete_breakpoint (bp); > } > > void > ... > > It makes sure delete_breakpoint is called only once, but I don't think this is the way to go, since it prevents the cleanup. Err, my intuition is that it doesn't make sense for operations like that, that update GDB's state (especially the tricky infrun / breakpoint state) in reaction to target events, to be interruptible by SIGTERM. It's just a recipe for ending up with half-baked state that is not up-to-date with the reality. I suppose that after receiving the SIGTERM, execution is interrupted by a QUIT macro and a gdb_exception_quit is thrown? Are you able to tell which QUIT causes this to happen, and show what the stack looks like at this point? Simon