From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ro0OH+ctBmoZqzoAWB0awg (envelope-from ) for ; Thu, 14 May 2026 16:17:43 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Vk15NQKQ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6836A1E0B1; Thu, 14 May 2026 16:17:43 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 7E96B1E067 for ; Thu, 14 May 2026 16:17:39 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D71324BAD170 for ; Thu, 14 May 2026 20:17:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D71324BAD170 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Vk15NQKQ Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 2DEFB4BA2E30 for ; Thu, 14 May 2026 20:17:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DEFB4BA2E30 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2DEFB4BA2E30 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778789832; cv=none; b=YgjIZ0OeGuA1dBgVAMDO1zGZ+rcDlb7Q+4OUs6McN7M7C1XhIZDuesgYW2HCeBXPZuTecoUvHjXpkcp2oLLCGEc5hCKEfLhuN1AVOPkbA6kOWnr5a26mrIzsQ0sRArm7tMeiXT1KUUCHVMDr2OFODKAlYrBRkUwBAAI4WTDcCDk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778789832; c=relaxed/simple; bh=LWnSQvZi2zE2vzwtC9Brqcn2mukHcVqyx38yur2howE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=Jc2suZz3ou6y16bxDJK52BG1jn98EzpANi/g5/ewFNyDRfF6/CqVeZiFjOEVa924qnDjzyuEGIelm1YMS8lBrqytAOPct+lqr5Z7dflbFEt/N7uJ7euHgGnCavzACWP/fgJkRwLXeB1gT7oi4nb/sOAZXQk1N/hLESXZkgcAGJw= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Vk15NQKQ DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2DEFB4BA2E30 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778789831; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oSKijVLy1pjmqdOODx5IR7TD2po64j3Vcj8wf1hft7A=; b=Vk15NQKQ/fhhG6pADCCr5/W1V5wQSe9jPLOi+QVp9xsqfcXkzterjZ/5e6Cikn6K1t3WLx 1qvSRJDVZxcNwqA7H11FRdHWUt5wkMLSJkwjN7CV3s9+3lCJ6fHqxBF14CcJ46/arNrqnq LGQrtIE1gyJMa2GcYr+vbGr7+8oIYrY= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-96-5FT9jqjuPcSyxEr1w6jAyw-1; Thu, 14 May 2026 16:17:10 -0400 X-MC-Unique: 5FT9jqjuPcSyxEr1w6jAyw-1 X-Mimecast-MFC-AGG-ID: 5FT9jqjuPcSyxEr1w6jAyw_1778789830 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 8D14E1800283 for ; Thu, 14 May 2026 20:17:09 +0000 (UTC) Received: from f42-zbm-amd (unknown [10.22.80.31]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A468F1800264; Thu, 14 May 2026 20:17:07 +0000 (UTC) Date: Thu, 14 May 2026 13:17:05 -0700 From: Kevin Buettner To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: pass inferior argument to inf_child_target::maybe_unpush_target Message-ID: <20260514131705.3d99bdfd@f42-zbm-amd> In-Reply-To: <4a06ca5986e36021a3ca4c47020cd3f8daee16a7.1778600715.git.aburgess@redhat.com> References: <4a06ca5986e36021a3ca4c47020cd3f8daee16a7.1778600715.git.aburgess@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: TXD_vj81UjxmhsoBqTj1yxBtARbCPodyP5a7IyC8jqs_1778789830 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On Tue, 12 May 2026 16:45:25 +0100 Andrew Burgess wrote: > Bug PR gdb/29944 highlights an issue where this assertion can trigger: > > thread-iter.c:109: internal-error: all_matching_threads_iterator: > Assertion `filter_target != nullptr' failed. > > The problem occurs when GDB is configured with these settings: > > set detach-on-fork off > set schedule-multiple on > set non-stop on > > There is a Python exit event listener registered like this: > > def exit_handler(_): > gdb.execute('inferior 1') > > gdb.events.exited.connect(exit_handler) > > Then the user runs an inferior which forks a child process, the > child (at some point) exits while the parent process continues > running. Then, at some future time, the parent process also exits. > > Initially we only have inferior 1, but when this inferior forks we now > have inferior's 1 and 2. Due to the settings GDB follows both, and > resumes both inferiors. > > On GNU/Linux, when the child, inferior 2, exits, we eventually end up > in inf_child_target::mourn_inferior. This then calls > generic_mourn_inferior which operates on the current inferior. This > includes calling exit_inferior, which is where the inferior_exit > observer is notified, and it is this that runs the Python 'exit' event > handlers. > > In our case the Python exit handler runs 'inferior 1', which changes > the current inferior. > > Back in inf_child_target::mourn_inferior we now call > maybe_unpush_target which potentially unpushes the inf_child_target > from the target stack of the current inferior. > > But notice, we already switched the current inferior to inferior 1. > This means that we just unpushed the inf_child_target from inferior 1, > which is still running, not inferior 2, which has exited. > > Later, when inferior 1 exits we end up in normal_stop and, because we > are in non-stop mode, we try to find the finish_ptid and finish_target > based on the inferior which just exited. In this case inferior 1. > But remember, inferior 1 no longer has a process stratum target, we > incorrectly unpushed it earlier when inferior 2 exited. > > We now initialise maybe_finish_thread_state, a > scoped_finish_thread_state object, using the finish_ptid, which is the > ptid of inferior 1, and finish_target, which is NULL. > > Eventually, later in normal_stop, the scoped_finish_thread_state runs, > which calls finish_thread_state, which calls all_non_exited_threads. > > This eventually calls > all_matching_threads_iterator::all_matching_threads_iterator to > iterate over the applicable threads, and, as the filter_ptid is that > of inferior 1 (i.e. not minus_one_ptid), and filter_target is NULL, > the assert triggers. > > The solution is simple enough, have > inf_child_target::maybe_unpush_target take the inferior to operate on, > rather than relying on the current_inferior being correct. It looks > like we might have run into something like this before as in > inf_child_target::follow_exec we temporarily change the current > inferior back prior to calling maybe_unpush_target. In that case it > is GDB's follow-exec-mode that was causing the problem. See: > > commit 737358ba1ed8b28820cc965f62027bb7417b132b > Date: Thu May 13 15:28:42 2021 -0400 > > gdb: maybe unpush target from old inferior in > inf_child_target::follow_exec > > I did consider having inf_child_target::maybe_unpush_target perform > the inferior switch for us, but after looking at what > maybe_unpush_target actually does, I don't think it is really > necessary for the current inferior to be set "correctly", given an > inferior pointer, we can just operate on that. > > So that's what I've done. maybe_unpush_target takes an 'inferior *' > argument, and it is that inferior from which we unpush the target. It > is no longer necessary to switch inferiors in follow_exec. > > There's a test that exposes the original assertion failure, which > passes with this patch. The gdb.base/foll-exec-mode.exp test, which > was added in commit 737358ba1ed8b288 also still passes after this > change. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29944 Thanks for that comprehensive explanation. Approved-by: Kevin Buettner