On Dec 8, 2025, at 7:36 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> 
>> Date: Mon, 8 Dec 2025 00:43:56 +0000
>> From: Kurt Miller <kurt@intricatesoftware.com>
>> 
>> I've been trying to debug an issue with the jvm but whenever a
>> thread exits that has previously been seen by gdb, I can't get
>> a full list of threads with thread info. I get this error instead:
>> "Couldn't get registers: No such process." For example:
>> 
>> (gdb) info threads
>>  Id   Target Id                                                Frame 
>>  1    thread 388840 of process 15667 ""                        futex () at /tmp/-:3
>>  2    thread 563387 of process 15667 ""                        futex () at /tmp/-:3
>>  3    thread 536589 of process 15667                           Couldn't get registers: No such process.
>> 
>> This is because we don't provide a function override for
>> thread_alive. This diff adds it (again copying NetBSD's
>> implementation) and is enough to fix the above problem.
>> 
>> However, this diff goes a step further and moves aways from using 
>> ptrace PT_GET_THREAD_FIRST/NEXT for finding threads and solely
>> utilizes sysctl KERN_PROC_PID | KERN_PROC_SHOW_THREADS for finding
>> threads. The advantage of this is that we can filter out threads
>> with SIDL or SDEAD states from gdb's view of the process's threads.
>> 
>> This should prevent a thread from being added in one of those
>> states and then removed when thread_alive returns false for it.
>> 
>> I've tested this on aarch64 with the jvm with threads being created
>> and exiting while stopping periodically to check on state. I've
>> checked both starting the process in gdb or attaching to the process.
>> I also double checked a single threaded program still works in gdb.
>> 
>> There are other ways to approach fixing this, like considering
>> threads in SIDL or SDEAD states alive - I'm not sure if that would
>> fix "Couldn't get registers: No such process." though. Another
>> aproach would be to have the kernel skip threads with
>> SIDL or SDEAD with ptrace PT_GET_THREAD_FIRST/NEXT.
>> 
>> Thoughts on my current approach or okays?
> 
> I don't think moving away from ptrace is a good idea; that is almost
> certainly going to introduce some nasty races.  If we need more
> information we should extend ptrace.  Adding a member to "struct
> ptrace_thread_state" shouldn't be hard.

Okay. I’ll head in that direction and rework this diff after I
add thread name to ptrace_thread_state.

-Kurt