forked from OSchip/llvm-project
df4ad3625f
D116372, while fixing one kind of a race, ended up creating a new one. The new issue could occur when one inferior thread exits while another thread initiates termination of the entire process (exit_group(2)). With some bad luck, we could start processing the exit notification (PTRACE_EVENT_EXIT) only to have the become unresponsive (ESRCH) in the middle of the MonitorCallback function. This function would then delete the thread from our list even though it wasn't completely dead (it stays zombified until we read the WIFEXITED event). The linux kernel will not deliver the exited event for the entire process until we process individual thread exits. In a pre-D116372 world, this wouldn't be a problem because we would read this event (even though we would not know what to do with it) with waitpid(-1). Now, when we issue invididual waitpids, this event will never be picked up, and we end up hanging. The fix for this is actually quite simple -- don't delete the thread in this situation. The thread will be deleted when the WIFEXITED event comes. This situation was kind of already tested by TestCreateDuringInstructionStep (which is how I found this problem), but it was mostly accidental, so I am also creating a dedicated test which reproduces this situation. |
||
|---|---|---|
| .. | ||
| bindings | ||
| cmake | ||
| docs | ||
| examples | ||
| include/lldb | ||
| packages/Python | ||
| resources | ||
| scripts | ||
| source | ||
| test | ||
| third_party/Python/module | ||
| tools | ||
| unittests | ||
| utils | ||
| .clang-format | ||
| .clang-tidy | ||
| .gitignore | ||
| CMakeLists.txt | ||
| CODE_OWNERS.txt | ||
| LICENSE.TXT | ||
| use_lldb_suite_root.py | ||