陶征霖 via llvm-dev
2015-Dec-21 05:30 UTC
[llvm-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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151221/9d94b884/attachment.html>
Greg Clayton via llvm-dev
2015-Dec-21 19:30 UTC
[llvm-dev] [lldb-dev] lldb -c corefile get segmentation fault on centos7
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.> On Dec 20, 2015, at 9:30 PM, 陶征霖 via lldb-dev <lldb-dev at lists.llvm.org> wrote: > > 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 > _______________________________________________ > lldb-dev mailing list > lldb-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Ted Woodward via llvm-dev
2015-Dec-21 20:21 UTC
[llvm-dev] [lldb-dev] lldb -c corefile get segmentation fault on centos7
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151221/aed1d555/attachment.html>
陶征霖 via llvm-dev
2015-Dec-22 06:32 UTC
[llvm-dev] [lldb-dev] lldb -c corefile get segmentation fault on centos7
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>