[all-commits] [llvm/llvm-project] df4ad3: [lldb/linux] Fix a race in handling of simultaneou...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: df4ad3625fad54d91b688564d5b2408aa943ebe4
      https://github.com/llvm/llvm-project/commit/df4ad3625fad54d91b688564d5b2408aa943ebe4
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2022-01-05 (Wed, 05 Jan 2022)

  Changed paths:
    M lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
    A lldb/test/API/functionalities/thread/concurrent_events/exit/Makefile
    A lldb/test/API/functionalities/thread/concurrent_events/exit/TestConcurrentThreadExit.py
    A lldb/test/API/functionalities/thread/concurrent_events/exit/main.cpp

  Log Message:
  -----------
  [lldb/linux] Fix a race in handling of simultaneous thread exits

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.