[Bug gdb/31203] [gdb] FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: python kill_and_detach()

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

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

--- Comment #13 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

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

commit 4ece39c56cfdd5647d4061f3c084b9de6f9e443c
Author: Tom de Vries <tdevries@suse.de>
Date:   Thu Jan 11 10:12:48 2024 +0100

    [gdb/testsuite] Extend gdb.base/kill-during-detach.exp

    I ran into the following FAIL:
    ...
    (gdb) python kill_and_detach()^M
    Traceback (most recent call last):^M
      File "<string>", line 1, in <module>^M
      File "<string>", line 7, in kill_and_detach^M
    gdb.error: Selected thread is running.^M
    Error while executing Python code.^M
    (gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true:
checkpoint_p=true: \
      python kill_and_detach()
    ...

    The FAIL happens as follows:
    - gdb is debugging a process A
    - a checkpoint is created, in other words, fork is called in the inferior,
      after which we have:
      - checkpoint 0 (the fork parent, process A), and
      - checkpoint 1 (the fork child, process B).
    - during checkpoint creation, lseek is called in the inferior (process A)
for
      all file descriptors, and it returns != -1 for at least one file
descriptor.
    - the process A continues in the background
    - gdb detaches, from process A
    - gdb switches to process B, in other words, it restarts checkpoint 1
    - while restarting checkpoint 1, gdb tries to call lseek in the inferior
      (process B), but this fails because gdb incorrectly thinks that inferior
B
      is running.

    This happens because linux_nat_switch_fork patches the pid of process B
into
    the current inferior and current thread which where originally representing
    process A.  So, because process A was running in the background, the
    thread_info fields executing and resumed are set accordingly, but they are
not
    correct for process B.

    There's a line in fork_load_infrun_state that fixes up the thread_info
field
    stop_pc, so fix this by adding similar fixups for the executing and resumed
    fields alongside.

    The FAIL did not always reproduce, so extend the test-case to reliably
    trigger this scenario.

    Tested on x86_64-linux.

    Approved-By: Kevin Buettner <kevinb@redhat.com>

    PR gdb/31203
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203

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