[lldb-dev] LLDB deadlocks trying to unwind

Malea, Daniel daniel.malea at intel.com
Thu Aug 22 14:49:09 PDT 2013


Ah, I see. I have not seen such an overflow, although I do most of my work
on Linux..

Jason is more experienced with the unwinder than I am...Jason, any
thoughts?


Dan

On 2013-08-22 5:32 PM, "Félix Cloutier" <felixcca at yahoo.ca> wrote:

>It's obviously the only thread, since frame #8 acquired the mutex first
>and frame #6 tries to acquire it again.
>
>I changed it to a recursive mutex, and now it crashes on a stack overflow
>instead of deadlocking. Here's an excerpt of the stack, from the
>initially calling frame (StackFrameList::GetFramesUpTo):
>
>#12543	UnwindMacOSXFrameBackchain::DoGetFrameInfoAtIndex(unsigned int,
>unsigned long long&, unsigned long long&) at
>lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp:59
>#12544	lldb_private::Unwind::GetFrameInfoAtIndex(unsigned int, unsigned
>long long&, unsigned long long&) at lldb/include/lldb/Target/Unwind.h:78
>#12545	lldb_private::StackFrameList::GetFramesUpTo(unsigned int) at
>lldb/source/Target/StackFrameList.cpp:332
>#12546	lldb_private::StackFrameList::GetFrameAtIndex(unsigned int) at
>lldb/source/Target/StackFrameList.cpp:521
>#12547	lldb_private::Thread::GetStackFrameAtIndex(unsigned int) at
>lldb/include/lldb/Target/Thread.h:357
>#12548	UnwindMacOSXFrameBackchain::DoGetFrameCount() at
>lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp:45
>#12549	lldb_private::Unwind::GetFrameCount() at
>lldb/include/lldb/Target/Unwind.h:52
>#12550	UnwindMacOSXFrameBackchain::DoGetFrameInfoAtIndex(unsigned int,
>unsigned long long&, unsigned long long&) at
>lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp:59
>#12551	lldb_private::Unwind::GetFrameInfoAtIndex(unsigned int, unsigned
>long long&, unsigned long long&) at lldb/include/lldb/Target/Unwind.h:78
>#12552	lldb_private::StackFrameList::GetFramesUpTo(unsigned int) at
>lldb/source/Target/StackFrameList.cpp:332
>#12553	lldb_private::StackFrameList::GetFrameAtIndex(unsigned int) at
>lldb/source/Target/StackFrameList.cpp:521
>#12554	lldb_private::Thread::GetStackFrameAtIndex(unsigned int) at
>lldb/include/lldb/Target/Thread.h:357
>#12555	UnwindMacOSXFrameBackchain::DoGetFrameCount() at
>lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp:45
>#12556	lldb_private::Unwind::GetFrameCount() at
>lldb/include/lldb/Target/Unwind.h:52
>#12557	UnwindMacOSXFrameBackchain::DoGetFrameInfoAtIndex(unsigned int,
>unsigned long long&, unsigned long long&) at
>lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp:59
>#12558	lldb_private::Unwind::GetFrameInfoAtIndex(unsigned int, unsigned
>long long&, unsigned long long&) at lldb/include/lldb/Target/Unwind.h:78
>#12559	lldb_private::StackFrameList::GetFramesUpTo(unsigned int) at
>lldb/source/Target/StackFrameList.cpp:304
>
>
>Le 2013-08-22 à 16:53:15, "Malea, Daniel" <daniel.malea at intel.com> a
>écrit :
>
>> Hmm, based on the stack trace you provided, it seems that
>>m_unwind_mutex should be initialized as a recursive mutex, just like
>>Process::m_thread_mutex.
>> 
>> Can you try to change the initialization of m_unwind_mutex in Unwind.h
>>to match that of Process:m_thread_mutex, and see if it helps? If not,
>>then it means some other thread is holding that mutex and more
>>investigation is requiredŠ
>> 
>> Cheers,
>> Dan
>> 
>> From: Félix Cloutier <felixcca at yahoo.ca<mailto:felixcca at yahoo.ca>>
>> Date: Thursday, 22 August, 2013 4:26 PM
>> To: "lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>"
>><lldb-dev at cs.uiuc.edu<mailto:lldb-dev at cs.uiuc.edu>>
>> Subject: [lldb-dev] LLDB deadlocks trying to unwind
>> 
>> LLDB, connected to a stub I'm building, is trying to produce a stack
>>trace of my stopped program but deadlocks instead:
>> 
>> #0 __psynch_mutexwait ()
>> #1 pthread_mutex_lock ()
>> #2 lldb_private::Mutex::Lock() at lldb/source/Host/common/Mutex.cpp:281
>> #3 lldb_private::Mutex::Locker::Lock(lldb_private::Mutex&) at
>>lldb/source/Host/common/Mutex.cpp:152
>> #4 lldb_private::Mutex::Locker::Locker(lldb_private::Mutex&) at
>>lldb/source/Host/common/Mutex.cpp:112
>> #5 lldb_private::Mutex::Locker::Locker(lldb_private::Mutex&) at
>>lldb/source/Host/common/Mutex.cpp:113
>> #6 lldb_private::Unwind::GetFrameCount() at
>>lldb/include/lldb/Target/Unwind.h:51
>> #7 UnwindMacOSXFrameBackchain::DoGetFrameInfoAtIndex(unsigned int,
>>unsigned long long&, unsigned long long&) at
>>lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp:59
>> #8 lldb_private::Unwind::GetFrameInfoAtIndex(unsigned int, unsigned
>>long long&, unsigned long long&) at lldb/include/lldb/Target/Unwind.h:78
>> #9 lldb_private::StackFrameList::GetFramesUpTo(unsigned int) at
>>lldb/source/Target/StackFrameList.cpp:304
>> #10 lldb_private::StackFrameList::ResetCurrentInlinedDepth() at
>>lldb/source/Target/StackFrameList.cpp:110
>> #11 lldb_private::StackFrameList::CalculateCurrentInlinedDepth() at
>>lldb/source/Target/StackFrameList.cpp:79
>> #12 lldb_private::Thread::ShouldStop(lldb_private::Event*) at
>>lldb/source/Target/Thread.cpp:752
>> #13 lldb_private::ThreadList::ShouldStop(lldb_private::Event*) at
>>lldb/source/Target/ThreadList.cpp:298
>> #14 lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*)
>>at lldb/source/Target/Process.cpp:3707
>> #15 
>>lldb_private::Process::HandlePrivateEvent(std::__1::shared_ptr<lldb_priva
>>te::Event>&) at lldb/source/Target/Process.cpp:3936
>> #16 lldb_private::Process::ConnectRemote(lldb_private::Stream*, char
>>const*) at lldb/source/Target/Process.cpp:3257
>> #17 CommandObjectProcessConnect::DoExecute(lldb_private::Args&,
>>lldb_private::CommandReturnObject&) at
>>lldb/source/Commands/CommandObjectProcess.cpp:1173
>> #18 lldb_private::CommandObjectParsed::Execute(char const*,
>>lldb_private::CommandReturnObject&) at
>>lldb/source/Interpreter/CommandObject.cpp:1038
>> #19 lldb_private::CommandInterpreter::HandleCommand(char const*,
>>lldb_private::LazyBool, lldb_private::CommandReturnObject&,
>>lldb_private::ExecutionContext*, bool, bool) at
>>lldb/source/Interpreter/CommandInterpreter.cpp:1825
>> #20 lldb_private::CommandObjectRegexCommand::DoExecute(char const*,
>>lldb_private::CommandReturnObject&) at
>>lldb/source/Interpreter/CommandObjectRegexCommand.cpp:89
>> #21 lldb_private::CommandObjectRaw::Execute(char const*,
>>lldb_private::CommandReturnObject&) at
>>lldb/source/Interpreter/CommandObject.cpp:1064
>> #22 lldb_private::CommandInterpreter::HandleCommand(char const*,
>>lldb_private::LazyBool, lldb_private::CommandReturnObject&,
>>lldb_private::ExecutionContext*, bool, bool) at
>>lldb/source/Interpreter/CommandInterpreter.cpp:1825
>> #23 lldb::SBCommandInterpreter::HandleCommand(char const*,
>>lldb::SBCommandReturnObject&, bool) at
>>lldb/source/API/SBCommandInterpreter.cpp:122
>> #24 Driver::HandleIOEvent(lldb::SBEvent const&) at
>>lldb/tools/driver/Driver.cpp:1083
>> #25 Driver::MainLoop() at lldb/tools/driver/Driver.cpp:1556
>> #26 main at lldb/tools/driver/Driver.cpp:1727
>> #27 start ()
>> 
>> #8 locks m_unwind_mutex and #6 tries to do the same thing.
>> 
>> The code path is unconditional (calling GetFrameInfoAtIndex with a
>>UnwindMacOSXFrameBackchain can only end in a deadlock, from what I can
>>see), so I'm not sure how I can prevent this from happening.
>> 
>> Félix
>





More information about the lldb-dev mailing list