diff options
author | Pedro Alves <pedro@palves.net> | 2022-02-22 10:15:07 +0000 |
---|---|---|
committer | Pedro Alves <pedro@palves.net> | 2022-03-10 11:35:54 +0000 |
commit | 8a841a3579bf1f8eb2414cbc3b2afae6bc59ac8a (patch) | |
tree | 48666126936243929a28942806e946f97994b19f /gdb/python | |
parent | 6cf20c46e37486b16b565046025c34b2e633dd33 (diff) | |
download | binutils-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')
0 files changed, 0 insertions, 0 deletions