[Bug 24958] New: lldb::SBDebugger::Terminate() results in Deadlock

Bug ID 24958
Summary lldb::SBDebugger::Terminate() results in Deadlock
Product lldb
Version unspecified
Hardware PC
OS Linux
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@lists.llvm.org
Reporter kratochwil@teco.edu
CC llvm-bugs@lists.llvm.org
Classification Unclassified

Created attachment 14945 [details]
Complete debug log, backtrace is at the end. The questionable mutex is

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_target = lldb_debugger.CreateTarget()
  lldb_process = lldb_target.AttachToProcessWithID()
  ... (doing stuff with modules)

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

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

I know that my code worked with svn revision 229496 (tested it a few hours

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...

labath@google.com changed bug 24958

What | Removed | Added |

  • | - | - |
    Status | NEW | RESOLVED |
    Resolution | — | FIXED |

Comment # 12 on bug 24958 from labath@google.com

I think we can close this now. Thanks for the help in debugging this.