llvm dev - Dec 2015 - 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>

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

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>

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>