From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id U02BBtIKrGrQTBcAWB0awg (envelope-from ) for ; Thu, 17 Sep 2026 11:44:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1789659857; bh=3rxLpIjwUPe548YZTPzR4Gt9LWN2XtZtv1b0YHIc7GI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=hdJA2hJr22/NE8X6cgrcTqOYL2+MMoLSWpL4atO9ajfOwKwApz3EmwwjSgSMK70ID rKmyev6bOr0pxQUQo4DswzgfvKgbvm1qJreaJKXUIKl3ZMYR8sLUrc+sNQHOah2sp2 VsfXAbkXD9MAWhc+b4CjK9jSp6AqqdgAbsGvJ+bQ= Received: by simark.ca (Postfix, from userid 112) id EFDE01E06A; Thu, 17 Sep 2026 11:44:17 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=HDhM3/yo; dkim-atps=neutral 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 365171E01F for ; Thu, 17 Sep 2026 11:44:17 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BD0E64BAE7CB for ; Thu, 17 Sep 2026 15:44:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BD0E64BAE7CB Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=HDhM3/yo Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id D85B44BA23E1 for ; Thu, 17 Sep 2026 15:43:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D85B44BA23E1 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 D85B44BA23E1 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789659832; cv=none; b=gI10ypmmSUev1NcY1+4yBPKVGamW/DkWJefK8bIFT+abdVfHAEwOlnOtWy2LLSHA+H3cUiqFE/oe8c/P0vINJ6JKm34j9TubjBRNemUDNrGJAsjVrjebLzQ+mGfeLxjJf9gFaoGuFMCdjk/ez+JTA0zGkqJBms6U01uZgSsnWGU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789659832; c=relaxed/simple; bh=3rxLpIjwUPe548YZTPzR4Gt9LWN2XtZtv1b0YHIc7GI=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=O1YJ0tvQvj+sAKFNbFK3+JaFgynGmgjVAnsKy4uPMVGG+RacRBIDDM25GP1hjbVMVj+EKPehxN43/P1dZqbJ2wAu0z/RSuis3N7yds+CMP1zCLRh4ZTL0Kyl6lsiFtaZsbnM2zrnCF6D1+0qBylkZGIn87Dxav2bFuLZQaWZ3bw= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=HDhM3/yo DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D85B44BA23E1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1789659831; bh=3rxLpIjwUPe548YZTPzR4Gt9LWN2XtZtv1b0YHIc7GI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=HDhM3/yoH42CCCoUUUfUbTlD6cxlc3XnvQXCy6S4u2uRqoHw6ws1kTq73jQvg2/OQ BgEdmAW6lHykdPlJKSM6hQL9IhvEoVqKSC86UlzLYAewWIL5Hiw0CwPPPBIX0dLN/0 42ODyGlypM8baZ3oXvGUe4P3vnB/iRBztcS6JCM0= Received: by simark.ca (Postfix) id 3F1521E01F; Thu, 17 Sep 2026 11:43:51 -0400 (EDT) Message-ID: <49282a00-e09a-48d1-8b88-9f197b397453@simark.ca> Date: Thu, 17 Sep 2026 11:43:50 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] gdb: rely on the first non-exited thread TPID when reading Linux procfs files To: Matthieu Longo , gdb-patches@sourceware.org Cc: Thiago Jung Bauermann References: <20260824162155.467233-1-matthieu.longo@arm.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20260824162155.467233-1-matthieu.longo@arm.com> Content-Type: text/plain; charset=UTF-8 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 8/24/26 12:21 PM, Matthieu Longo wrote: > On Linux, /proc/ is keyed by the thread-group leader PID. When > the leader has exited, some /proc//... entries become unavailable > even though another thread is still alive. This can happen, for instance, > when the main thread calls pthread_exit() and another thread continues > the execution (existing test: gcore-stale-thread). > > This causes GDB to fail to read procfs entries such as cmdline, cwd, > exe, maps, and smaps when it uses 'current_inferior ()->pid' after the > thread-group leader has exited. > > Fix this by adding inferior::first_non_exited_thread(), which returns > the PTID of the first non-exited thread of the inferior. Use its LWP ID No longer true (it returns the thread_info, not the ptid). > when accessing procfs entries that only need a representative live LWP > belonging to the process. > > This is a best-effort choice of a thread that is expected to still exist > in the target. Since GDB's view of the threads list may be stale, the > selected thread may already have exited by the time it is accessed. > Callers must therefore still be prepared to handle that case. > > Update the following functions: > - linux_info_proc > - linux_process_address_in_memtag_page > - linux_find_memory_regions_full > - linux_fill_prpsinfo > - linux_address_in_shadow_stack_mem_range > to use the first non-exited thread's LWP ID instead of the inferior PID > when constructing procfs paths. > > Add a new test in gdb.threads. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31207 > > Reviewed-by: Thiago Jung Bauermann > --- > gdb/inferior.c | 12 +++ > gdb/inferior.h | 11 +++ > gdb/linux-tdep.c | 90 +++++++++++++------ > ...access-procfs-while-thread-leader-exited.c | 48 ++++++++++ > ...cess-procfs-while-thread-leader-exited.exp | 78 ++++++++++++++++ > 5 files changed, 211 insertions(+), 28 deletions(-) > create mode 100644 gdb/testsuite/gdb.threads/access-procfs-while-thread-leader-exited.c > create mode 100644 gdb/testsuite/gdb.threads/access-procfs-while-thread-leader-exited.exp > > diff --git a/gdb/inferior.c b/gdb/inferior.c > index 8c619ffec5a..f6d77799ac2 100644 > --- a/gdb/inferior.c > +++ b/gdb/inferior.c > @@ -250,6 +250,18 @@ inferior::find_thread (ptid_t ptid) > > /* See inferior.h. */ > > +thread_info * > +inferior::first_non_exited_thread () const > +{ > + auto it = this->ptid_thread_map.cbegin (); > + if (it != this->ptid_thread_map.cend ()) > + return it->second; > + else > + return nullptr; > +} I was thinking that it would make more sense to name the method "any_non_exited_thread", since there's no ordering of the threads (ptid_thread_map is an unordered_map). Then I saw we already have the free function any_non_exited_thread_of_inferior. It doesn't use the same strategy to find a non-exited thread, but the intent seems to be the same. But one thing it does is that it prefers the currently selected thread: /* Prefer the current thread, if there's one. */ if (inf == current_inferior () && inferior_ptid != null_ptid) return inferior_thread (); I think there is a bug there, because if the selected thread is zombie leader (which happens in your test), then it will return it, even if it is exited. We could fix that and then use that function. I'm thinking it would actually be nice if GDB prioritized the selected thread for /proc access here. Most things are the same for the whole process, which non-exited thread we use is not important for those. But there are some things in /proc that are thread-specific (things like stat counters I tihnk), so it would allow the user to select one particular thread and then get information about that thread. I am trying it, I'll send something soon to the list. Simon