<div dir="ltr"><div><div>Hi Ted,<br><br></div>I am able to load the executable binary without the corefile.<br>[root@dn-cn-controller-p2acv bin]# lldb /usr/local/myproject/bin/cnode<br>(lldb) target create "/usr/local/myproject/bin/cnode"<br>Current executable set to '/usr/local/myproject/bin/cnode' (x86_64).<br>(lldb)<br><br></div><div>If this is a known issue, any workround for this? Or just swith to a lower version?<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-22 4:21 GMT+08:00 Ted Woodward <span dir="ltr"><<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="#0563C1" vlink="#954F72" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">This looks like the ArchSpec merge issue, where if the target ArchSpec is not valid it doesn’t set the machine correctly.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><a href="https://llvm.org/bugs/show_bug.cgi?id=25106" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=25106</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">--<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Qualcomm Innovation Center, Inc.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> lldb-dev [mailto:<a href="mailto:lldb-dev-bounces@lists.llvm.org" target="_blank">lldb-dev-bounces@lists.llvm.org</a>] <b>On Behalf Of </b>??? via lldb-dev<br><b>Sent:</b> Sunday, December 20, 2015 11:31 PM<br><b>To:</b> LLDB; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><b>Subject:</b> [lldb-dev] lldb -c corefile get segmentation fault on centos7<u></u><u></u></span></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><div><div><p class="MsoNormal" style="margin-bottom:12.0pt">Hi,<u></u><u></u></p></div><div><p class="MsoNormal">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:<br>[root@dn-cn-controller-4fbd4 data1]# lldb -c a.corefile /usr/local/myproject/bin/cnode<br><b>(lldb) target create "/usr/local/myproject/bin/cnode" --core "a.corefile"</b><br>Segmentation fault (core dumped)<br><br><b>And then I tried gdb to check the lldb call stack:</b><br><b>(gdb) info threads</b><br>  Id   Target Id         Frame<br>  3    Thread 0x7f81c4795700 (LWP 64) 0x00007f81c9ed46d5 in pthread_cond_wait@@GLIBC_2.3.2 ()<br>   from /lib64/libpthread.so.0<br>  2    Thread 0x7f81ce580740 (LWP 59) 0x00007f81c9ed46d5 in pthread_cond_wait@@GLIBC_2.3.2 ()<br>   from /lib64/libpthread.so.0<br>* 1    Thread 0x7f81c3f94700 (LWP 65) 0x00007f81cbe00630 in lldb_private::ArchSpec::GetMachine() const ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br><b>(gdb) bt</b><br>#0  0x00007f81cbe00630 in lldb_private::ArchSpec::GetMachine() const ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#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<br>#2  0x00007f81cc153a24 in RegisterContextCorePOSIX_x86_64::RegisterContextCorePOSIX_x86_64(lldb_private::Thread&, lldb_private::RegisterInfoInterface*, lldb_private::DataExtractor const&, lldb_private::DataExtractor const&) ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#3  0x00007f81cc151e5e in ThreadElfCore::CreateRegisterContextForFrame(lldb_private::StackFrame*) ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#4  0x00007f81cc1523b3 in ThreadElfCore::GetRegisterContext() ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#5  0x00007f81cbfae9e2 in lldb_private::StackFrameList::GetFramesUpTo(unsigned int) ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#6  0x00007f81cbfaf3e7 in lldb_private::StackFrameList::ResetCurrentInlinedDepth() ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#7  0x00007f81cbfd32e2 in lldb_private::Thread::ShouldStop(lldb_private::Event*) ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#8  0x00007f81cbfd98d2 in lldb_private::ThreadList::ShouldStop(lldb_private::Event*) ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#9  0x00007f81cbf997bb in lldb_private::Process::ShouldBroadcastEvent(lldb_private::Event*) ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#10 0x00007f81cbf998a1 in lldb_private::Process::HandlePrivateEvent(std::shared_ptr<lldb_private::Event>&) ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#11 0x00007f81cbf9a77a in lldb_private::Process::RunPrivateStateThread(bool) ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#12 0x00007f81cbdf7db2 in lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) ()<br>   from /opt/dependency/tools/bin/../lib64/liblldb.so.3.7<br>#13 0x00007f81c9ed0dc5 in start_thread () from /lib64/libpthread.so.0<br>#14 0x00007f81c91c821d in clone () from /lib64/libc.so.6<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Any suggesstion about why lldb -c core dump?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">Thanks,<u></u><u></u></p></div><p class="MsoNormal">Zhenglin<u></u><u></u></p></div></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>陶征霖<br>Pivotal</div></div></div>
</div>