From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CUBDH2pGIWpNCjQAWB0awg (envelope-from ) for ; Thu, 04 Jun 2026 05:33:30 -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=dR/f1vqI; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7BEA71E062; Thu, 04 Jun 2026 05:33:30 -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 E5A971E062 for ; Thu, 04 Jun 2026 05:33:29 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8D7A54BAE7C4 for ; Thu, 4 Jun 2026 09:33:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8D7A54BAE7C4 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=dR/f1vqI 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 36ED34BA540B for ; Thu, 4 Jun 2026 09:32:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 36ED34BA540B 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 36ED34BA540B 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=1780565538; cv=none; b=CLonZX05hGjLJVAwwAcLNj7Dwc6tF6y32xX16L6+MHWEfPj3QA5LPzqTn/D5xdb+FE1K+8PX4NOhhMUQJXZ1S4CyxarRq56uLJuZp0+4hveGGM2DQVFiVhaqb21ipkTx1e4F5cjZgKuIEWpaKUC9IRAykDLkFBX2R94NzwzeGPY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780565538; c=relaxed/simple; bh=hRqoM3RCXDGqF8fIJdMqXWXpyljHSqDiDIG7jdRRuOc=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=twhxHmS3+HscHS4T31+8EuUSUTIk44wCzrOxrimw+JzIrNZ3N/WhqTYJpljoEtLoP/yehW0CpwybEP9HxRzcvHAMa9BcPjtSXftqIeBk3UL4Xmp3x9dEhy7E0HGmetWZwQWaEynYkkd7TesxC4JQcznrYGzMpeCa8IwZFy0lXjE= 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=dR/f1vqI DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 36ED34BA540B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780565532; 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=Ee9g89hnk/iRJrZT+XJinqBvX3tw7D5aZwaevHDAffE=; b=dR/f1vqIA+2a0AHiUbQMciYXPt5/52Cu+s1Drmy3RzgcnkWOG9LomqD5XdzC6sfWBwLbKI tDFEMnwQWJPwvQAAcCzAO6goclJ8oYrBI0fxVpz/MoN7BjgaSRGzBVQktgUk6/js9lHJh/ SnMO/IuYmcBGflj0V6rciYCx6Wlq7jc= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-488-qE0aLM7EMgyND-q4boqnww-1; Thu, 04 Jun 2026 05:32:11 -0400 X-MC-Unique: qE0aLM7EMgyND-q4boqnww-1 X-Mimecast-MFC-AGG-ID: qE0aLM7EMgyND-q4boqnww_1780565531 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-460163035e3so322205f8f.2 for ; Thu, 04 Jun 2026 02:32:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780565530; x=1781170330; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=FAFtyzSwXDLbkIhw5Fy0Ie7+1gHt9s1Hx8zXuGrg6FQ=; b=Uk4M4SEvpSPC8rGXKwcnu242XW4BKRuIhEUQeDOKQIQmd5CEdluZtxFM1igA71Zx1s iaCRngqWBcmuzBnRl63XVGXViK87FbIdyh2s2ve/QIXaedNuL3uG1ms8SDoSx7chs5EA CzyqICJIR0CYUv9qrpcmxWKqCGc9OBzFHx9dLya1/puyJQGcvpPw1ggLiIFEmof7j9n2 B9BUkboLCRwKXSkhcH3ZMHWq9dw9Fp2Dh8HDeoQb5YZx2l55aWE7eoPMHDxGPwGC/sir DUtjERpeS0EhwK/hXJkZgT7HlJBQJotTGnxln4I+2byL5YjDCfJh6HuWwQcGsBQe+9b2 9yNg== X-Forwarded-Encrypted: i=1; AFNElJ/WzmH2A1oY1roRSV0RNmHi92ka5TSKsThhaHzXV5d50uTyIQacyYxs7Kt4nZksVV9iYxA0cOHQ1qvy2w==@sourceware.org X-Gm-Message-State: AOJu0YxbjS+FqUk6OPr9ugeiuCBxMPfWBlNc7tcMNofP9nk6XDWy1Zvw tDXkEeMFr251lc+bjqCT86GVJZ+zA6TSNOq6iTyHfsenbZC/Bu/ZoZuIHQEsde0aN6u9Yda6fQ9 45GqF5QhiWYfH1F5gVDYaSJKLQsGDcwVuKbwuZBwPdfmQtNtfuRYpe17EF03W4mo= X-Gm-Gg: Acq92OE6/laQt8ybyNq04AFyFPjIVDxFEJpYQzXcjdvmVDJueov8g583HRfr3LwUvm5 VwHcg1C1Eu+JpKIe7ZZyWBFSx+BZfOrM263NdKJzCk10WT6sj7SrMDw/CH0CZOZ6wZWR1qqj3nC pme4sCEaRbSY5cHVp1hgFVWLHg5GUNLlr7fklfdgBaQnxd/BfZicFJ9rpDKWstn5WsqryPxau0M E6YGtPM+Hz2CQB7EnYfeY+IlVjEs8iNteS1UiIYYGxHXUHWTFt6S2/3a7E2b81ER+NfzLL8KVql GfGKN0WazaSJwUi8jrJRzMeQHB+V3+BXIRDsJSy4CgEFVpNQynDUu+9nIgIwm1fX6JQnfoBwzf9 e9oKG0XVsxkt43BDbMpB4MZbWXQ== X-Received: by 2002:adf:f807:0:b0:45e:633e:a7cc with SMTP id ffacd0b85a97d-46021936939mr8158623f8f.24.1780565530503; Thu, 04 Jun 2026 02:32:10 -0700 (PDT) X-Received: by 2002:adf:f807:0:b0:45e:633e:a7cc with SMTP id ffacd0b85a97d-46021936939mr8158586f8f.24.1780565530116; Thu, 04 Jun 2026 02:32:10 -0700 (PDT) Received: from localhost ([213.31.44.97]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f2f67c6sm15096530f8f.16.2026.06.04.02.32.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2026 02:32:09 -0700 (PDT) From: Andrew Burgess To: Lancelot SIX Cc: Luis.Machado@amd.com, gdb-patches@sourceware.org Subject: Re: [PATCH 2/3] gdb: refactor core_target ::close and ::detach functions In-Reply-To: References: Date: Thu, 04 Jun 2026 10:32:08 +0100 Message-ID: <87bjdqslbb.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: _JTeDB5Am6H2USaELrY7ZIAo1ASFzOKQ1nLgee-DY_M_1780565531 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 Lancelot SIX writes: > 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 t= o >> + 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 () !=3D nullptr); >> + >> + /* If we called ::detach before calling ::close then the inferior wil= l >> + 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, b= y >> + 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 select= ed, >> + then we can tell if exit_core_file_inferior has already been calle= d by >> + checking if no thread is now selected. */ >> + if (inferior_ptid !=3D 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) > =09 target_detach (inf, from_tty); > =09else > =09 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=E2=80=AFdebugging 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? Lancelot, Sorry for the breakage, and thanks for the great analysis. I'll take a look at getting this fixed asap. Hopefully will get something posted next week. Thanks, Andrew > > Best, > Lancelot. > >> =20 >> /* 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 ()); >> }