aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/lib
diff options
context:
space:
mode:
authorPedro Alves <pedro@palves.net>2022-02-22 10:15:07 +0000
committerPedro Alves <pedro@palves.net>2022-03-10 11:35:54 +0000
commit8a841a3579bf1f8eb2414cbc3b2afae6bc59ac8a (patch)
tree48666126936243929a28942806e946f97994b19f /gdb/python/lib
parent6cf20c46e37486b16b565046025c34b2e633dd33 (diff)
downloadbinutils-8a841a3579bf1f8eb2414cbc3b2afae6bc59ac8a.zip
binutils-8a841a3579bf1f8eb2414cbc3b2afae6bc59ac8a.tar.gz
binutils-8a841a3579bf1f8eb2414cbc3b2afae6bc59ac8a.tar.bz2
Re-add zombie leader on exit, gdbserver/linux
Same as the previous patch, but for GDBserver. In summary, the current zombie leader detection code in linux-low.cc has a race -- if a multi-threaded inferior exits just before check_zombie_leaders finds that the leader is now zombie via checking /proc/PID/status, check_zombie_leaders deletes the leader, assuming we won't get an event for that exit (which we won't in some scenarios, but not in this one), which is a false-positive scenario, where the whole process is simply exiting. Later when we see the last LWP in our list exit, we report that LWP's exit status as exit code, even though for the (real) parent process, the exit code that counts is the child's leader thread's exit code. Like for GDB, the solution here is to: - only report whole-process exit events for the leader. - re-add the leader back to the LWP list when we finally see it exit. Change-Id: Id2d7bbb51a415534e1294fff1d555b7ecaa87f1d
Diffstat (limited to 'gdb/python/lib')
0 files changed, 0 insertions, 0 deletions