[all-commits] [llvm/llvm-project] 769d70: Recommit "[lldb/Core] Fix a race in the Communicat...

[Pavel Labath via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 769d7041cc1457dc2c5bcd040f24d530af48b76b
      https://github.com/llvm/llvm-project/commit/769d7041cc1457dc2c5bcd040f24d530af48b76b
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2020-04-09 (Thu, 09 Apr 2020)

  Changed paths:
    M lldb/source/Core/Communication.cpp
    M lldb/unittests/Core/CMakeLists.txt
    A lldb/unittests/Core/CommunicationTest.cpp

  Log Message:
  -----------
  Recommit "[lldb/Core] Fix a race in the Communication class"

The synchronization logic in the previous had a subtle bug. Moving of
the "m_read_thread_did_exit = true" into the critical section made it
possible for some threads calling SynchronizeWithReadThread call to get
stuck. This could happen if there were already past the point where they
checked this variable. In that case, they would block on waiting for the
eBroadcastBitNoMorePendingInput event, which would never come as the
read thread was blocked on getting the synchronization mutex.

The new version moves that line out of the critical section and before
the sending of the eBroadcastBitNoMorePendingInput event, and also adds
some comments to explain why the things need to be in this sequence:
- m_read_thread_did_exit = true: prevents new threads for waiting on
  events
- eBroadcastBitNoMorePendingInput: unblock any current thread waiting
  for the event
- Disconnect(): close the connection. This is the only bit that needs to
  be in the critical section, and this is to ensure that we don't close
  the connection while the synchronizing thread is mucking with it.

Original commit message follows:

Communication::SynchronizeWithReadThread is called whenever a process
stops to ensure that we process all of its stdout before we report the
stop. If the process exits, we first call this method, and then close
the connection.

However, when the child process exits, the thread reading its stdout
will usually (but not always) read an EOF because the other end of the
pty has been closed. In response to an EOF, the Communication read
thread closes it's end of the connection too.

This can result in a race where the read thread is closing the
connection while the synchronizing thread is attempting to get its
attention via Connection::InterruptRead.

The fix is to hold the synchronization mutex while closing the
connection.

I've found this issue while tracking down a rare flake in some of the
vscode tests. I am not sure this is the cause of those failures (as I
would have expected this issue to manifest itself differently), but it
is an issue nonetheless.

The attached test demonstrates the steps needed to reproduce the race.
It will fail under tsan without this patch.

Reviewers: clayborg, JDevlieghere

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77295