Bug ID 24958
Summary lldb::SBDebugger::Terminate() results in Deadlock
Component All Bugs
Created attachment 14945 [details] Complete debug log, backtrace is at the end. The questionable mutex is 0x7ffff7dc2fc0. While using the C++ API (Scripting Bridge) of lldb (svn revision 247535), the following (abbreviated) call sequence results in a Deadlock: lldb_debugger = lldb::SBDebugger::Create() lldb_debugger.SetAsync(true) lldb_target = lldb_debugger.CreateTarget() lldb_process = lldb_target.AttachToProcessWithID() ... (doing stuff with modules) lldb::SBDebugger::Terminate() I compiled Mutex.cpp with both debug macros DEBUG_LOG and ENABLE_MUTEX_ERROR_CHECKING enabled - the latter results in my program receiving a SIGABRT instead of a deadlock, due to the mutex error checking code. I noticed that the call to lldb_private::Debugger::Terminate() ends up in lldb_private::Mutex::Lock(). Here a mutex is being locked which was already locked / unlocked a few times earlier (see attachment: the mutex has the ID 0x7ffff7dc2fc0). I know that my code worked with svn revision 229496 (tested it a few hours ago). The debug log is quite lengthy - sorry for that. At the bottom you'll find a complete gdb backtrace. I'll recompile lldb without the error checking macros to see if there is more than one thread running when the deadlock occurs. I'll be back in a minute...