[lldb-dev] lldb::SBDebugger::Terminate() hangs in deadlock
Stefan Kratochwil via lldb-dev
lldb-dev at lists.llvm.org
Mon Sep 28 03:05:10 PDT 2015
thanks for your quick reply.
I filed a bug at https://llvm.org/bugs/show_bug.cgi?id=24958.
I'll try to determine a more precise revision range for that issue. I am
currently using svn (checking out lldb manually into llvm/tools).
Do you have a recommended workflow for git in such a situation? git
bisect with subtree / submodule?
On 09/28/2015 10:24 AM, Pavel Labath wrote:
> Thanks for the report. Since you are suspecting a deadlock, could you
> post a backtrace of all the threads (thread apply all backtrace). It
> would be best to move this discussion to a bug in llvm.org/bugs.
>> I am currently using svn revision 247535 of llvm and lldb, and I know that my code was working with svn revision 229496
> This sounds like a pretty big revision range. It would help if you
> could narrow it down a bit.
> On 28 September 2015 at 09:12, Stefan Kratochwil via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
>> I've got a problem with lldb deadlocking upon a call to
>> I am currently using svn revision 247535 of llvm and lldb, and I know that
>> my code was working with svn revision 229496.
>> In short, I am doing the following steps:
>> lldb_debugger = lldb::SBDebugger::Create()
>> lldb_target = lldb_debugger.CreateTarget()
>> lldb_process = lldb_target.AttachToProcessWithID()
>> ... (doing stuff with modules)
>> The last call results in a deadlock.
>> I enabled the DEBUG_LOG and ENABLE_MUTEX_ERROR_CHECKING macros within
>> Mutex.cpp and found out that a mutex is getting locked whose ID never came
>> up in the log before. This mutex has no owner, so it should be lockable -
>> but it isn't...
>> A gdb backtrace with the last few debug messages can be found here:
>> Does anyone have an idea what is going on here? Am I missing something?
>> Thanks in advance!
>> Stefan Kratochwil
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
More information about the lldb-dev