[Lldb-commits] [lldb] [lldb] Fix deadlock when scripted frame providers load on private state thread (PR #191913)

Med Ismail Bennani via lldb-commits lldb-commits at lists.llvm.org
Tue Apr 14 17:07:30 PDT 2026


================
@@ -1491,30 +1491,46 @@ bool Thread::IsAnyProviderActive() {
 StackFrameListSP Thread::GetStackFrameList() {
   std::lock_guard<std::recursive_mutex> guard(m_frame_mutex);
 
-  // If a provider is currently fetching frames, return the provider's input
-  // frames instead of m_curr_frames_sp. m_curr_frames_sp IS the
-  // SyntheticStackFrameList, and accessing it would trigger provider code on
-  // THIS thread too. That is dangerous because:
-  //  - On the provider's own host thread: circular dependency / deadlock.
-  //  - On the private state thread: the provider may call EvaluateExpression
-  //    which needs the private state thread to process events -> deadlock.
-  //  - On any other thread: would run the provider concurrently.
-  // Returning the input (parent) frames is always safe.
+  // Determine if we must avoid running provider code on this call.
+  // Providers execute arbitrary Python that can call back into the SB API or
+  // evaluate expressions. That is unsafe in two situations:
+  //
+  //  1. Re-entrancy: a provider is already active on some host thread.
+  //     - Same thread: the provider's get_frame_at_index() calls
+  //       HandleCommand("bt") or accesses input_frames, which re-enters
+  //       GetStackFrameList() -> infinite recursion.
+  //     - Private state thread: the provider called EvaluateExpression()
+  //       which resumed the process via RunThreadPlan; the private state
+  //       thread must process the resulting stop event, but if it tries to
+  //       build the synthetic frame list it will re-enter the provider ->
+  //       deadlock.
+  //     - Any other thread: would run the provider concurrently with the
+  //       thread that is already mid-construction.
+  //
+  //  2. Current thread is a private state thread.
----------------
medismailben wrote:

same here

https://github.com/llvm/llvm-project/pull/191913


More information about the lldb-commits mailing list