From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id DMi1Gs2qIGo/EjMAWB0awg (envelope-from ) for ; Wed, 03 Jun 2026 18:29:33 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=amd.com header.i=@amd.com header.a=rsa-sha256 header.s=selector1 header.b=HczEKrdE; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 581FB1E024; Wed, 03 Jun 2026 18:29:33 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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 autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 107BD1E024 for ; Wed, 03 Jun 2026 18:29:31 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1ABE74BA2E23 for ; Wed, 3 Jun 2026 22:29:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1ABE74BA2E23 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=amd.com header.i=@amd.com header.a=rsa-sha256 header.s=selector1 header.b=HczEKrdE Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazlp170120005.outbound.protection.outlook.com [IPv6:2a01:111:f403:c105::5]) by sourceware.org (Postfix) with ESMTPS id 7A49B4BA2E0A for ; Wed, 3 Jun 2026 22:28:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7A49B4BA2E0A Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=amd.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7A49B4BA2E0A Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=2a01:111:f403:c105::5 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1780525735; cv=pass; b=s9crlwsvLJwaQQtXEOJ8wjTxRwD+tcoGdRfBG2vY31v86uqZDenTssNvwzSj1XEVEgOp0/AiFyIOJMQU9KDY7qo18rD/QLqz0PvyIrgBNEVTMp5vLh/ZZnT7JFUsKG0ZXYlx1r8pUFSs14Zn/yWrEjJ2/8h8cx5fwW4bUVyFR5c= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1780525735; c=relaxed/simple; bh=JtpbECiw6Oxh178mWw77OjobvvaysPAnJM3DxRUB6YE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=KpYbKyoLdp4SQTisxzWBB6KoI+oSWvSoF+EW6lKE1NdVhb9qNNSBRkmj1O/ARnN77UUCIj1vXfcixO4FFhTE4E0BaecrgfoIDHY49zev6BEtzQJ5yRQsVooa19bGtyN8Qv6Y+q9u6NklTLBRKmkDA1+lxuZo/efcaMxKRXrqdo0= ARC-Authentication-Results: i=2; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=amd.com header.i=@amd.com header.a=rsa-sha256 header.s=selector1 header.b=HczEKrdE DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7A49B4BA2E0A ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=QIFQWkPoqtlRkHCoBpGlpsnzjFu2jdEOOZbMDeL/ZXT0gp0EU/Ik8QzClizi4w5+oEY7L5JL/hZ+eGOrMz66Knp3waGaPiHTov25X9r/YZtbApcbv/F0ZexSv2/2MsreTfeqsWIzjtzAfmASM9XpA0jlOPdo6X+TeMdPXcKNaRS878AsJC0pV6yQmglWdJtrBGO+OWGlWL3D2R2uCwkmr/qZyvb/X0urCeUWqxjUPJi6BKKq7hhWUyzryYP7acNCRLmOaqNb8f87hy/HAeYB4U71fiQV0kcQJcbZPpJ8GuFUsRu7gsZSUZUgGTtfoCbYg+DpOJXmrXd4aPFI/7ZZ/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SprqFwqTyayhu/T5IB37+vn4DEcntuSEiuhexB16xCI=; b=BMP6FGPxYr46qimNi2RghF+/z0UqF116eMpxG+al05tj9b+MDT9TSrrPahT1AQfCN1k7t8gPSvzjnScWyw0RxXBl2FV74VW3rgg6nBXVBv8aXmBnEWVuJa6owG6dq/gOn/UIURMgwJngitF7WQ3n84q/7MrojWG+uplQaB5UHpNrjX+mjITlkPv9LBOlbn9FpsL2dr2rLjVEv0MO3xuLXWSSRiy5CFrQz+6AiFdqEwCN7ooVJU0CdNr2PxwAyJE8XEuF3nXKCpx8dZPbBeV/dXpONduIDFWpl/A3l1oAjgUtrU38xccMzyd0tQ44cLWXExpd2RkuIJ8aY7QMRIaUyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=redhat.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SprqFwqTyayhu/T5IB37+vn4DEcntuSEiuhexB16xCI=; b=HczEKrdE18sVwmyD8P9f6kJtILv2qYRQYWMPA2RSdOYDfI/6r9aeAGY5NJlg9Rbl/sb+f11cnACto6gpRxvAhRivE7hv7bh33zCtMy+mxQYC0x+dn37tsVf3Vh2U3y3BLyQmBsgreM7V+gr0twiBBXeEX2rVbOePSgXSmtpq0vU= Received: from SJ0PR03CA0138.namprd03.prod.outlook.com (2603:10b6:a03:33c::23) by BN7PPF28614436A.namprd12.prod.outlook.com (2603:10b6:40f:fc02::6c9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.92.7; Wed, 3 Jun 2026 22:28:50 +0000 Received: from SJ1PEPF000023CE.namprd02.prod.outlook.com (2603:10b6:a03:33c:cafe::69) by SJ0PR03CA0138.outlook.office365.com (2603:10b6:a03:33c::23) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.92.7 via Frontend Transport; Wed, 3 Jun 2026 22:28:50 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb07.amd.com; pr=C Received: from satlexmb07.amd.com (165.204.84.17) by SJ1PEPF000023CE.mail.protection.outlook.com (10.167.244.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.92.5 via Frontend Transport; Wed, 3 Jun 2026 22:28:50 +0000 Received: from khazad-dum (10.180.168.240) by satlexmb07.amd.com (10.181.42.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.41; Wed, 3 Jun 2026 17:28:48 -0500 Date: Wed, 3 Jun 2026 23:28:40 +0100 From: Lancelot SIX To: Andrew Burgess CC: , Subject: Re: [PATCH 2/3] gdb: refactor core_target ::close and ::detach functions Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: satlexmb08.amd.com (10.181.42.217) To satlexmb07.amd.com (10.181.42.216) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PEPF000023CE:EE_|BN7PPF28614436A:EE_ X-MS-Office365-Filtering-Correlation-Id: 8737f0fe-f735-4bb1-b2b5-08dec1bf7c6c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; ARA:13230040|36860700016|82310400026|376014|1800799024|6133799003|5023799004|3023799007|18002099003|22082099003|11063799006|56012099006; X-Microsoft-Antispam-Message-Info: khDpQsLUJ+Ts9K6vaBEARBu9j4aqhf+0KD00kwLTbdtENO/ZolBf78XWFTbpBr3Kw/FN5czCt2AotcT3b9KrhwQ2IAeLbq0Ye0xJPRAOd8fNB8NPGA7hAAeXAT0xIuZVyHm0AE+uN880eosgWn6z5DCepF9ailnqJ6FdXGtfRTgaq2cc3bMabRvYuk6XpZozS/2jfkDDFop+AFQ4e+WTVMXM1/0yQgXcqaxley8edL9h9IASLRMucAx4GZWnhdEU1fZR/isMfI5EQMl1Rsb444W7Q0tgNFR8o4mZ20xZZJU6XvMam0ayUy7Iu85GZ78yba+gGDRumz3ygRmnaSUukv8ImNFwnIQjY1jsPMnuvxSwkr/UPVFlif+fllkCtv3k91FOefziulYhIPdGYJj7uDkWgJgCWC2aZi9FuMR/D5ZRzB2Mzdk948gtQqMRByji/Xjw8/Bpuf4cmDtITgss8ipK40y1giJpvvzxpWiGasnTbavwQ9yd2OioWcrMlLQeqdgZs8n+SooEXnxjgjfKT3jFKc5cls3TvfUkxfSORnIHnH0fmsN1gN+ZrBHL7fl8/7cqrJVu9M+f+qSflveFPK/wd1aj9E1T9obuHGFkyNaJ5n5HBcTTdjDNnF1qs6ynsB3FjGchNZb95edtuZEmnunxYO+y0SDMauJaLHH3f2xayermwigbwdBpzgLDHetODtqViSfJrqmua7XEYklcYeLs3XGn0p3iWA0Um1rwUnE= X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:satlexmb07.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230040)(36860700016)(82310400026)(376014)(1800799024)(6133799003)(5023799004)(3023799007)(18002099003)(22082099003)(11063799006)(56012099006); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: gYRlqCiFWzdKQ5plpVPl9j70/mkvDGpZak6tfIXK4pZK+8PRlz6AuT12j/8liOKTBT+U6V66WR4eBVfPrs6TDUhpyCflHMHqXc/rImRmmpCZbIzoItY1A4jMTbfdOimspup1ozwBO3VnUZQyQlu9eaX292EqwZJtBiZVd1F9KCJK4rj5jvrmKutgvoFMMSmymfivKNuJnFs+oRe/YeeYwhF3NfQHCuiXV0WbhSNQUBmngspOLJ7b+bnHpPofQX+KaysDSFbZalxiLpAtGlmKam33tu6YM+RrvJHU9jLkP1AjM0dxOntmMS8jAQNBoZW5rc/EODHvbTlTfFNAvNRQbyDeObVrpDj9c9fIL1f/GjQ73xpWkeQQ1OgmANtXXsUdBZC1+pYy7XOIAuuyqqVcvzJnuTdJeU9uLY8DDc9+4w+xkvl7ke5K5vr/bqURrCsx X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2026 22:28:50.2981 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8737f0fe-f735-4bb1-b2b5-08dec1bf7c6c X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d; Ip=[165.204.84.17]; Helo=[satlexmb07.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SJ1PEPF000023CE.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PPF28614436A 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 Mon, Mar 30, 2026 at 04:30:52PM +0100, Andrew Burgess wrote: > void > core_target::close () > { > - clear_core (); > + /* The core BFD is set when the core_target is created and attached to > + the inferior. It is never explicitly cleared, instead m_core_bfd will > + have its reference count reduced when the core_target is deleted. */ > + gdb_assert (this->core_bfd () != nullptr); > + > + /* If we called ::detach before calling ::close then the inferior will > + have already been exited. This will happen if the user clears the > + core file with the 'core-file' or 'detach' commands. > + > + However, if the user just causes the core_target to be unpushed, by > + pushing an alternative target, e.g. 'target remote ....', then we will > + not call ::detach before calling ::close. > + > + In the former case we don't want to exit the inferior twice; this is > + mostly harmless except it causes two 'exited' events to be emitted in > + the Python API, which isn't ideal. > + > + As opening a core_target always ensures that some thread is selected, > + then we can tell if exit_core_file_inferior has already been called by > + checking if no thread is now selected. */ > + if (inferior_ptid != null_ptid) > + exit_core_file_inferior (); Hi Andrew, We are observing a behaviour change after your change in the downstream ROCgdb port. Long story short is: when doing "exit" with a core file opened, the "inferior_exit" observer is not called at all. When calling "exit", we execute: quit_command quit_force inferior::pop_all_targets pop_all_targets_above (dummy_stratum) >From there, pop_all_targets does: switch_to_inferior_no_thread (this); while (top_target ()->stratum () > stratum) unpush_target_and_assert (top_target ()); The switch_to_inferior_no_thread sets inferior_ptid to null_ptid, then we unpush the core_target, decrement its refcount and end up here in core_target::close. Because inferior_ptid is null_ptid, we skip calling exit_core_file_inferior. One would expect that we detach before reaching this point, and quit_force tries to do so: for (inferior *inf : all_inferiors ()) kill_or_detach (inf, from_tty); However, kill_or_detach explicitly does not call target_detach for core files: /* Leave core files alone. */ if (target_has_execution ()) { if (inf->attach_flag) target_detach (inf, from_tty); else target_kill (); } Because exit_core_file_inferior is not called, we never call "exit_inferior (current_inferior ())", and therefore fail to notify the "inferior_exit" observer. In our case, we notice this because we use the inferior_exit observer to detach the GPU side of the process. Because we fail to do this detach, we leave some unclean state in our GPU debugging library, which eventually causes complaints (i.e. segfault) when calling global destructors. Given this scenario, I expect the last part of the comment regarding the guarantee of having a thread selected is invalid. I have not looked too deeply into a solution yet, but I can. Given that the core_target is not shareable, could each instance have a "detached" flag which could be used in placed of checking inferior_ptid against null_ptid? Best, Lancelot. > > /* Core targets are heap-allocated (see core_target_open), so here > we delete ourselves. */ > delete this; > + > + /* Notify that the core file has changed. This is intentionally done > + after the core_target is deleted as nothing in here depends on the > + core_target itself, the core_target has already been removed from the > + inferior's target stack by this point. */ > + gdb::observers::core_file_changed.notify (current_inferior ()); > }