[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