maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

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.

llvm-svn: 187522
This commit is contained in:
Daniel Malea 2013-07-31 20:21:20 +00:00
parent 957c8b1c70
commit a012d3a68e
1 changed files with 1 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
lldb/source/Target/Process.cpp
View File

@ -5418,6 +5418,7 @@ Process::RunThreadPlan (ExecutionContext &exe_ctx,
if (GetThreadList().SetSelectedThreadByIndexID (selected_tid) && selected_stack_id.IsValid()) if (GetThreadList().SetSelectedThreadByIndexID (selected_tid) && selected_stack_id.IsValid())
{ {
// We were able to restore the selected thread, now restore the frame: // 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); StackFrameSP old_frame_sp = GetThreadList().GetSelectedThread()->GetFrameWithStackID(selected_stack_id);
if (old_frame_sp) if (old_frame_sp)
GetThreadList().GetSelectedThread()->SetSelectedFrame(old_frame_sp.get()); GetThreadList().GetSelectedThread()->SetSelectedFrame(old_frame_sp.get());