mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2025-01-08 00:52:54 +00:00
769d7041cc
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 |
||
|---|---|---|
| .. | ||
| 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 | ||