[Bug testsuite/31312] attach-many-short-lived-threads gives inconsistent results

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31312

--- Comment #28 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thiago Bauermann
<bauermann@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c930a077225ec042287379d8e49b4d547f97d1ba

commit c930a077225ec042287379d8e49b4d547f97d1ba
Author: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Date:   Sun Mar 17 02:40:05 2024 -0300

    gdb/nat/linux: Fix attaching to process when it has zombie threads

    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>

-- 
You are receiving this mail because:
You are on the CC list for the bug.