[llvm-dev] [lldb-dev] lldb -c corefile get segmentation fault on centos7
陶征霖 via llvm-dev
llvm-dev at lists.llvm.org
Mon Dec 21 22:32:21 PST 2015
Hi Ted,
I am able to load the executable binary without the corefile.
[root at 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).
(lldb)
If this is a known issue, any workround for this? Or just swith to a lower
version?
2015-12-22 4:21 GMT+08:00 Ted Woodward <ted.woodward at codeaurora.org>:
> This looks like the ArchSpec merge issue, where if the target ArchSpec is
> not valid it doesn’t set the machine correctly.
>
>
>
> https://llvm.org/bugs/show_bug.cgi?id=25106
>
>
>
> 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.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] *On Behalf Of *???
> via lldb-dev
> *Sent:* Sunday, December 20, 2015 11:31 PM
> *To:* LLDB; llvm-dev at lists.llvm.org
> *Subject:* [lldb-dev] lldb -c corefile get segmentation fault on centos7
>
>
>
> Hi,
>
> 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 at 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?
>
>
>
> Thanks,
>
> Zhenglin
>
--
陶征霖
Pivotal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151222/9ef15bdd/attachment.html>
More information about the llvm-dev
mailing list