From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oV7oJ6+sIWrVgTQAWB0awg (envelope-from ) for ; Thu, 04 Jun 2026 12:49:51 -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=jRc1ABKr; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9C66E1E0A6; Thu, 04 Jun 2026 12:49:51 -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 09A431E062 for ; Thu, 04 Jun 2026 12:49:51 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2F2BF4BA2E33 for ; Thu, 4 Jun 2026 16:49:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F2BF4BA2E33 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=jRc1ABKr Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id C1B774BA2E0D for ; Thu, 4 Jun 2026 16:49:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C1B774BA2E0D 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 C1B774BA2E0D Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780591761; cv=none; b=LfHqZlQ0d6WTUEpptKW8OincycjLew1p/RHaYtDCTURqRYTCYCvF48iK3SIGrO+LzgOqtj+eMkIm0u949yPvK8KCrsMc5fmpFXlKreXAmA1HKI4B1JSndrpTEiOGxvip7iadI4mMIl+GYnGuTPxSdUK12+Drc/6Rq8CKHGPkwhc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780591761; c=relaxed/simple; bh=BVTtq1o+iJe2+0PgG3iF0evzymEz4Qz6rgtdZ5mfFso=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=D+dYEYGfnNkUxw60E9yb3vx1XR33KZfk9nNgJRbSIi5bxj3trKPFj8r5zexb1tUPGHb+uuiwLUKqwivAm/OxAPjJ2QU3OWz2UpEbub/qfK/ZAkfamWH3xYnXn8hqzyG1rzEAyliSPtEBOB4fKUnm04dhPQR47kOwwos4YI2qlyo= 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=jRc1ABKr DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C1B774BA2E0D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780591761; 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=wq+i4szBd8nMIQDy9CjjvfLDWhWC7UkRw5BG7parmUk=; b=jRc1ABKr8kpiBr42UH3QqsJUz2TxdZWfYg78WX81kNU2hzF1xyw9V4BH4mMtUrvF7nd03N fGIldn8dvAfiKtdupfb9LvZKTK9FGJ2e6NP239rnC1QUkZ85jKgAMv++Kfoi5y67kT9lkW swVcLagdnFEakmJ0JesTQhiVAL1G7os= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-479-qEuJCTKoPpenqIfkCK_M-g-1; Thu, 04 Jun 2026 12:49:20 -0400 X-MC-Unique: qEuJCTKoPpenqIfkCK_M-g-1 X-Mimecast-MFC-AGG-ID: qEuJCTKoPpenqIfkCK_M-g_1780591759 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-490bde3d239so7649165e9.1 for ; Thu, 04 Jun 2026 09:49:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780591759; x=1781196559; 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=ds8rLkf7LcN0mfU/N5DD5cD/HckGVmBk5iJ1LhZuBpk=; b=s5kCr7CYNA9XMwo3W9RTIVXg+aaT2D3gfrbytBB7EQ890WkZGXHEyrOUTDc2tKGsKj c0LEb8pCoMo0UYlDr5jhI1RIOu+tOuRdWw6QUJXxyNOtkKefdVENqPAxGBCmiA4tyOpU k9aaGt/RAfhuPDkTCw8gXMHxSZ4kmT09XaHvQc1D6Mis6xsMKnnwQ4JgzjJQfArXRkj9 P9PLbY2o+cAb3/DLjiHDjxDjo31WX5ic07aQOVSqRhhWI+I2/AQjZkD3pImEm92AiSE6 anI4y/OcikBKKJelKUVvceyrXSxFXrZPs5uF/xAbL/ADu5He5nAxtsTGluix13zlnh5/ O93g== X-Forwarded-Encrypted: i=1; AFNElJ9Y7E0FTnx+x24fIZ0HkJdOLv1DX69nKUpUbF0dw7sIju5TuG19LvgKXc9MCrs4ucnU74jnicBRuyQbYg==@sourceware.org X-Gm-Message-State: AOJu0YyMs6GpdA9IOAgibEu8oWeKlSbO2WGnLx5YrkWngxCB35+3+OVP bFVMYVBchG4ha6yR364QppZXKIiVcvotNEl7l7gDfgY0P/xvbTZw90jARMgavy0LdpsBYoXkVUi apAzTHP5DOQQfcUv8sWy3yhm+lAbxYpGz5YsXVDDXAy0vnLPZUv56CqQeYVv4Vh1fJhivEuk= X-Gm-Gg: Acq92OFfWVRrV4bylKbaQEp/W6WBpRO2Ynw36RgHMjtQGp26BMTiOdvS3ELh3yj+2qA iB0bHfVYBPT4hwKO4YwMLmDdT8UPReF6V3NPgcJEOjjxwzPWM55qBX+PMvJGfL8dSvaqcWCRcxC 5FyWJ/BbJl9ASs9+V+WEzlU9rTvF5rWV2h4fVs8T/BLgWYrc0vi/EzVAcj4hpL2EP2SEv5sGY6P qRlJv6O9bqJT3b8HErbgsUo62JXxgR3K/Sk83YNVID4Wl0n7PbzzGKnJ4Li+ETDkdRFbLAUE2Jb +iTDHs9jLnHzDLj96GgPyTbKGluVUrA4SVc11p/wck03qNAra12OuDIGPdmiLDbFHfrAUDgfQOV S06XOSeqte7YyY0HSZj6oISHtYA== X-Received: by 2002:a05:600c:1c1f:b0:490:be9e:fd03 with SMTP id 5b1f17b1804b1-490be9efee6mr52986875e9.7.1780591759063; Thu, 04 Jun 2026 09:49:19 -0700 (PDT) X-Received: by 2002:a05:600c:1c1f:b0:490:be9e:fd03 with SMTP id 5b1f17b1804b1-490be9efee6mr52986475e9.7.1780591758623; Thu, 04 Jun 2026 09:49:18 -0700 (PDT) Received: from localhost ([213.31.44.97]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f2dc412sm18355217f8f.4.2026.06.04.09.49.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jun 2026 09:49:18 -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: <87bjdqslbb.fsf@redhat.com> References: <87bjdqslbb.fsf@redhat.com> Date: Thu, 04 Jun 2026 17:49:16 +0100 Message-ID: <8733z2s12r.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ZpXXPbrzswT2FQ46aTKm2ajQ-5g8xrdCYkfiQ4LUrAQ_1780591759 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 Andrew Burgess writes: > 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 = 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 () !=3D nullptr); >>> + >>> + /* If we called ::detach before calling ::close then the inferior wi= ll >>> + have already been exited. This will happen if the user clears th= e >>> + 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 emitte= d in >>> + the Python API, which isn't ideal. >>> + >>> + As opening a core_target always ensures that some thread is selec= ted, >>> + then we can tell if exit_core_file_inferior has already been call= ed 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. Fix posted here: https://inbox.sourceware.org/gdb-patches/fce47c4e13bd626b3b3bc074fd51ab1e= d23ad0e3.1780591573.git.aburgess@redhat.com Thanks, Andrew