[Lldb-commits] [lldb] [lldb] Fix scripted frame provider cross-thread re-entrant deadlock (PR #208242)
Jonas Devlieghere via lldb-commits
lldb-commits at lists.llvm.org
Wed Aug 19 09:03:20 PDT 2026
================
@@ -5992,8 +5992,42 @@ Target::TargetEventData::GetModuleListFromEvent(const Event *event_ptr) {
return module_list;
}
+APIMutexHandle::APIMutexHandle() = default;
+
+APIMutexHandle::APIMutexHandle(lldb::TargetSP target_sp)
+ : m_target_sp(std::move(target_sp)) {}
+
+void APIMutexHandle::lock() {
+ if (m_target_sp)
+ m_target_sp->GetAPIMutex().lock();
+ else
+ m_standalone_mutex.lock();
+}
+
+void APIMutexHandle::unlock() {
+ if (m_target_sp)
+ m_target_sp->GetAPIMutex().unlock();
+ else
+ m_standalone_mutex.unlock();
+}
+
+bool APIMutexHandle::try_lock() {
+ if (m_target_sp)
+ return m_target_sp->GetAPIMutex().try_lock();
+ return m_standalone_mutex.try_lock();
+}
+
std::recursive_mutex &Target::GetAPIMutex() {
Policy policy = PolicyStack::Get().Current();
+
+ // Every caller still locks *something* here, rather than a no-op: since
+ // the mutex is thread-local, that lock never contends with whatever
+ // other thread holds the real one.
----------------
JDevlieghere wrote:
My original comment about a Python script that locks an SBMutex inside a callback and unlocks it outside, is still unaddressed, right?
https://github.com/llvm/llvm-project/pull/208242
More information about the lldb-commits
mailing list