Re: [PATCH v2] gdb: rely on the first non-exited thread TPID when reading Linux procfs files

[Simon Marchi <simark@simark.ca>]

On 8/24/26 12:21 PM, Matthieu Longo wrote:
> On Linux, /proc/<pid> is keyed by the thread-group leader PID. When
> the leader has exited, some /proc/<pid>/... 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 <thiago.bauermann@linaro.org>
> ---
>  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