lldb -c corefile get segmentation fault on centos7


I build llvm+clang+lldb 3.7 successfully on centos7, and lldb -p PID works pretty well. However when I tried lldb -c corefile executable_bin, lldb itself core dumpped. Attached the following core info which is debugged by gdb:
[root@dn-cn-controller-4fbd4 data1]# lldb -c a.corefile /usr/local/myproject/bin/cnode
(lldb) target create “/usr/local/myproject/bin/cnode” --core “a.corefile”
Segmentation fault (core dumped)

And then I tried gdb to check the lldb call stack:
(gdb) info threads
Id Target Id Frame
3 Thread 0x7f81c4795700 (LWP 64) 0x00007f81c9ed46d5 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0
2 Thread 0x7f81ce580740 (LWP 59) 0x00007f81c9ed46d5 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib64/libpthread.so.0

  • 1 Thread 0x7f81c3f94700 (LWP 65) 0x00007f81cbe00630 in lldb_private::ArchSpec::GetMachine() const ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    (gdb) bt
    #0 0x00007f81cbe00630 in lldb_private::ArchSpec::GetMachine() const ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #1 0x00007f81cc20458f in RegisterContextPOSIX_x86::RegisterContextPOSIX_x86(lldb_private::Thread&, unsigned int, lldb_private::RegisterInfoInterface*) () from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #2 0x00007f81cc153a24 in RegisterContextCorePOSIX_x86_64::RegisterContextCorePOSIX_x86_64(lldb_private::Thread&, lldb_private::RegisterInfoInterface*, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&) ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #3 0x00007f81cc151e5e in ThreadElfCore::CreateRegisterContextForFrame(lldb_private::StackFrame*) ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #4 0x00007f81cc1523b3 in ThreadElfCore::GetRegisterContext() ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #5 0x00007f81cbfae9e2 in lldb_private::StackFrameList::GetFramesUpTo(unsigned int) ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #6 0x00007f81cbfaf3e7 in lldb_private::StackFrameList::ResetCurrentInlinedDepth() ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #7 0x00007f81cbfd32e2 in lldb_private::thread::ShouldStop(lldb_private::Event*) ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #8 0x00007f81cbfd98d2 in lldb_private::ThreadList::ShouldStop(lldb_private::Event*) ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #9 0x00007f81cbf997bb in lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*) ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #10 0x00007f81cbf998a1 in lldb_private::Process::HandlePrivateEvent(std::shared_ptr<lldb_private::Event>&) ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #11 0x00007f81cbf9a77a in lldb_private::Process::RunPrivateStateThread(bool) ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #12 0x00007f81cbdf7db2 in lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) ()
    from /opt/dependency/tools/bin/…/lib64/liblldb.so.3.7
    #13 0x00007f81c9ed0dc5 in start_thread () from /lib64/libpthread.so.0
    #14 0x00007f81c91c821d in clone () from /lib64/libc.so.6

Any suggesstion about why lldb -c core dump?



Something is probably NULL, like maybe the register context from frame 1 or frame 2. Make this crash again and then switch to each frame and dump all of the local variables.

This looks like the ArchSpec merge issue, where if the target ArchSpec is not valid it doesn’t set the machine correctly.


Zhenglin, can you load /usr/local/myproject/bin/cnode in lldb, without the core file? It should have a valid ArchSpec, but your backtrace looks like the backtrace from bug 25106, which doesn’t have a valid target ArchSpec.

Hi Ted,

I am able to load the executable binary without the corefile.
[root@dn-cn-controller-p2acv bin]# lldb /usr/local/myproject/bin/cnode
(lldb) target create “/usr/local/myproject/bin/cnode”
Current executable set to ‘/usr/local/myproject/bin/cnode’ (x86_64).

If this is a known issue, any workround for this? Or just swith to a lower version?