Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[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 <[email protected]> PR gdb/31203 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203
- Loading branch information