diff options
author | Daniel Malea <daniel.malea@intel.com> | 2013-07-31 20:21:20 +0000 |
---|---|---|
committer | Daniel Malea <daniel.malea@intel.com> | 2013-07-31 20:21:20 +0000 |
commit | 666a1f8a7b5caa18abdee9503bc20c49b0542e59 (patch) | |
tree | 77f0a0272a5a53a03771438d1f671ce374701bcd | |
parent | a224c7c673a433ef9f6673929a5eb8508bd8e73d (diff) | |
download | lldb-666a1f8a7b5caa18abdee9503bc20c49b0542e59.tar.gz |
Fix lock hierarchy violation in Process (lock ordering of ThreadList mutex and StackFrameList mutex)
- this fix ensures the ThreadList mutex is always locked before the StackFrameList mutex
Situation where deadlock could occur (without this fix):
Thread 1 is in Process::WillResume and locks the ThreadList mutex (on entry), and subsequently calls StackFrameList::Clear() which locks the StackFrameList mutex.
Meanwhile, thread 2 is in Process::RunThreadPlan and calls Thread::SetSelectedFrame() (which locks the StackFrameList mutex) before calling GetSelectedThread (which attempts to lock the ThreadList mutex)
In my testing on both Linux and Mac OS X, I was unable to reproduce any hangs with this patch applied.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@187522 91177308-0d34-0410-b5e6-96231b3b80d8
-rw-r--r-- | source/Target/Process.cpp | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/source/Target/Process.cpp b/source/Target/Process.cpp index d2aac468c..6edb9390d 100644 --- a/source/Target/Process.cpp +++ b/source/Target/Process.cpp @@ -5418,6 +5418,7 @@ Process::RunThreadPlan (ExecutionContext &exe_ctx, if (GetThreadList().SetSelectedThreadByIndexID (selected_tid) && selected_stack_id.IsValid()) { // We were able to restore the selected thread, now restore the frame: + Mutex::Locker lock(GetThreadList().GetMutex()); StackFrameSP old_frame_sp = GetThreadList().GetSelectedThread()->GetFrameWithStackID(selected_stack_id); if (old_frame_sp) GetThreadList().GetSelectedThread()->SetSelectedFrame(old_frame_sp.get()); |