Re: [PATCH v2 3/3] gdb/nat/linux: Fix attaching to process when it has zombie threads

[Thiago Jung Bauermann <thiago.bauermann@linaro.org>]

Pedro Alves <pedro@palves.net> writes:

> On 2024-04-20 06:56, Thiago Jung Bauermann wrote:
>> When GDB attaches to a multi-threaded process, it calls
>> linux_proc_attach_tgid_threads () to go through all threads found in
>> /proc/PID/task/ and call attach_proc_task_lwp_callback () on each of
>> them.  If it does that twice without the callback reporting that a new
>> thread was found, then it considers that all inferior threads have been
>> found and returns.
>> 
>> The problem is that the callback considers any thread that it hasn't
>> attached to yet as new.  This causes problems if the process has one or
>> more zombie threads, because GDB can't attach to it and the loop will
>> always "find" a new thread (the zombie one), and get stuck in an
>> infinite loop.
>> 
>> This is easy to trigger (at least on aarch64-linux and powerpc64le-linux)
>> with the gdb.threads/attach-many-short-lived-threads.exp testcase, because
>> its test program constantly creates and finishes joinable threads so the
>> chance of having zombie threads is high.
>> 
>> This problem causes the following failures:
>> 
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: attach (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: no new threads (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint
>> always-inserted on (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break break_fn (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 1
>> (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 2
>> (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 3
>> (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: reset timer in the
>> inferior (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: print seconds_left
>> (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: detach (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint
>> always-inserted off (timeout)
>> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: delete all breakpoints,
>> watchpoints, tracepoints, and catchpoints in delete_breakpoints (timeout)
>> ERROR: breakpoints not deleted
>> 
>> The iteration number is random, and all tests in the subsequent iterations
>> fail too, because GDB is stuck in the attach command at the beginning of
>> the iteration.
>> 
>> The solution is to make linux_proc_attach_tgid_threads () remember when it
>> has already processed a given LWP and skip it in the subsequent iterations.
>> 
>> PR testsuite/31312
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31312
>> 
>> Reviewed-By: Luis Machado <luis.machado@arm.com>
>
> Approved-By: Pedro Alves <pedro@palves.net>

Thank you!

> BTW, after seeing the other patches after patch #1, I do agree with giving names
> to the stat fields.

Great. You did bring up interesting points about them though, so it was
an interesting exercise.

-- 
Thiago