[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
show more ...
[lldb/linux] Fix a race in handling of simultaneous thread exitsD116372, while fixing one kind of a race, ended up creating a new one.The new issue could occur when one inferior thread exits while
[lldb/linux] Fix a race in handling of simultaneous thread exitsD116372, while fixing one kind of a race, ended up creating a new one.The new issue could occur when one inferior thread exits while anotherthread 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 themiddle of the MonitorCallback function. This function would then deletethe thread from our list even though it wasn't completely dead (it stayszombified until we read the WIFEXITED event). The linux kernel will notdeliver the exited event for the entire process until we processindividual thread exits.In a pre-D116372 world, this wouldn't be a problem because we would readthis event (even though we would not know what to do with it) withwaitpid(-1). Now, when we issue invididual waitpids, this event willnever be picked up, and we end up hanging.The fix for this is actually quite simple -- don't delete the thread inthis situation. The thread will be deleted when the WIFEXITED eventcomes.This situation was kind of already tested byTestCreateDuringInstructionStep (which is how I found this problem), butit was mostly accidental, so I am also creating a dedicated test whichreproduces this situation.