[lldb-dap] Correctly report breakpoints as resolved on macOS (#129589) #10459
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
) When adding SBLock, I realized you always have to add a new header in two places: LLDB.h and headers.swig. I can't think of a reason the latter can't use the umbrella header and avoid the duplication. (cherry picked from commit 4322d03)
Expose u target API mutex through the SB API. This is motivated by lldb-dap, which is built on top of the SB API and needs a way to execute a series of SB API calls in an atomic manner (see llvm#131242). We can solve this problem by either introducing an additional layer of locking at the DAP level or by exposing the existing locking at the SB API level. This patch implements the second approach. This was discussed in an RFC on Discourse [0]. The original implementation exposed a move-only lock rather than a mutex [1] which doesn't work well with SWIG 4.0 [2]. This implement the alternative solution of exposing the mutex rather than the lock. The SBMutex conforms to the BasicLockable requirement [3] (which is why the methods are called `lock` and `unlock` rather than Lock and Unlock) so it can be used as `std::lock_guard<lldb::SBMutex>` and `std::unique_lock<lldb::SBMutex>`. [0]: https://discourse.llvm.org/t/rfc-exposing-the-target-api-lock-through-the-sb-api/85215/6 [1]: llvm#131404 [2]: https://discourse.llvm.org/t/rfc-bumping-the-minimum-swig-version-to-4-1-0/85377/9 [3]: https://en.cppreference.com/w/cpp/named_req/BasicLockable (cherry picked from commit 50949eb)
The `locked` variable can be accessed from the asynchronous thread until the call to f.wait() completes. However, the variable is scoped in a lexical block that ends before that, leading to a use-after-free. (cherry picked from commit 0b8c8ed)
…ckport) Protect the various SetBreakpoint functions with the API mutex. This fixes a race condition between the breakpoint being created and the DAP label getting added. This was causing `TestDAP_breakpointEvents.py` to be flaky. Fixes llvm#131242.
|
@swift-ci test |
adrian-prantl
approved these changes
Apr 8, 2025
|
@swift-ci test |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherrypick upstream changes to mark breakpoints as resolved on macOS