<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 26, 2016 at 11:31 PM, Jeffrey Tan <span dir="ltr"><<a href="mailto:jeffrey.fudan@gmail.com" target="_blank">jeffrey.fudan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thanks David. I meant to send to lldb maillist, but glad to hear response here. <div><br></div><div>Our binary is built from gcc:</div><div>String dump of section '.comment':</div><div> [ 1] GCC: (GNU) 4.9.x-google 20150123 (prerelease) </div><div><br></div><div>Is there any similar flags we should use? </div></div></blockquote><div><br></div><div>If it's the sort of issue I'm guessing it might be (though I have very little evidence to go on/I don't remember the possible/specific failure modes, etc) you might try <span style="color:rgb(0,0,0);font-family:monospace;font-size:medium">-femit-class-debug-always with GCC<br><br>That said, to provide a more accurate diagnosis/help, a reduced test case would be really helpful (the smallest C++ input (counting headers, etc, as well - tools like creduce/delta/multidelta can help reduce test cases, though they're better on compiler crashes than trying to preserve a running program, etc)</span><span style="color:rgb(0,0,0);font-family:monospace;font-size:medium"> that produces the problem)</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>By doing "strings -a [binary] | grep -i gcc", I found the following flags being used:</div><div>GNU C++ 4.9.x-google 20150123 (prerelease) -momit-leaf-frame-pointer -m64 -mtune=generic -march=x86-64 -g -O3 -O3 -std=gnu++11 -ffunction-sections -fdata-sections -fstack-protector -fno-omit-frame-pointer -fdebug-prefix-map=/home/engshare/third-party2/icu/53.1/src/icu=/home/engshare/third-party2/icu/53.1/src/icu -fdebug-prefix-map=/home/engshare/third-party2/icu/53.1/src/build-gcc-4.9-glibc-2.20-fb/no-pic=/home/engshare/third-party2/icu/53.1/src/icu -fno-strict-aliasing --param ssp-buffer-size=4<br></div><div><br></div><div>Also, per reading <a href="https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Debugging-Options.html" target="_blank">https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Debugging-Options.html</a>, seems that we should use "<span style="color:rgb(0,0,0);font-family:monospace;font-size:medium">-gdwarf-2</span>" to generate only standard DWARF format? I think I might need to chat with our build team but want to know which flag I need ask them first.</div><div><br></div><div>Btw: I tried gdb against the same binary which seems to get better result:</div><div><br></div><div><div>(gdb) p corpus</div><div>$3 = (const std::string &) @0x7fd133cfb888: {</div><div> static npos = 18446744073709551615, store_ = {</div><div> static kIsLittleEndian = <optimized out>,</div><div> static kIsBigEndian = <optimized out>, {</div><div> small_ = "www", '\000' <repeats 20 times>, "\024", ml_ = {</div><div> data_ = 0x777777 <std::_Any_data::_M_access<void folly::fibers::Baton::waitFiber<folly::fibers::FirstArgOf<facebook::servicerouter::RequestDispatcherBase<facebook::servicerouter::ThriftDispatcher>::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise<facebook::servicerouter::RequestDispatcherBase<facebook::servicerouter::ThriftDispatcher>::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}, void>::type::value_type folly::fibers::await<facebook::servicerouter::RequestDispatcherBase<facebook::servicerouter::ThriftDispatcher>::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise<facebook::servicerouter::RequestDispatcherBase<facebook::servicerouter::ThriftDispatcher>::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&, folly::fibers::FirstArgOf<folly::fibers::FirstArgOf<facebook::servicerouter::RequestDispatcherBase<facebook::servicerouter::ThriftDispatcher>::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise<facebook::servicerouter::RequestDispatcherBase<facebook::servicerouter::ThriftDispatcher>::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}, void>::type::value_type folly::fibers::await<facebook::servicerouter::RequestDispatcherBase<facebook::servicerouter::ThriftDispatcher>::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise<facebook::servicerouter::RequestDispatcherBase<facebook::servicerouter::ThriftDispatcher>::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}, void>::type::value_type)::{lambda(folly::fibers::Fiber&)#1}*>() const+25> "\311\303UH\211\345H\211}\370H\213E\370]ÐUH\211\345H\203\354\020H\211}\370H\213E\370H\211\307\350~\264\312\377\220\311\303UH\211\345SH\203\354\030H\211}\350H\211u\340H\213E\340H\211\307\350\236\377\377\377H\213\030H\213E\350H\211\307\350O\264\312\377H\211ƿ\b", size_ = 0,</div><div> capacity_ = 1441151880758558720}}}}</div></div><span class=""><font color="#888888"><div><br></div><div>Jeffrey</div><div><br></div><div><br></div></font></span></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 26, 2016 at 8:22 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">If you're going to use clang built binaries with lldb, you'll want to pass -fstandalone-debug - this is the default on platforms where lldb is the primary debugger (Darwin and freebsd)</p>
<p dir="ltr">Not sure if that is the problem you are seeing, but will be a problem sooner or later</p>
<div class="gmail_quote"><div><div>On Mar 26, 2016 4:16 PM, "Jeffrey Tan via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr">Hi,<div><br></div><div>While dogfooding our lldb based IDE on Linux, I am seeing a lot of variable evaluation errors related to DW_TAG_member which prevents us from release the IDE. Can anyone help to confirm if they are known issues? If not, any information you need to troubleshoot this issue?</div><div><br></div><div>Here is one example:</div><div><br><div><div>(lldb) fr v</div><div><b>error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member '_M_pod_data' refers to type 0x10bb1e99 which extends beyond the bounds of 0x10b9a901</b></div><div><b>error: biggrep_master_server_async 0x10b98edc: DW_TAG_member 'small_' refers to type 0x10bb1d9f which extends beyond the bounds of 0x10b98ed3</b></div><div><b>error: biggrep_master_server_async 0x10baf034: DW_TAG_member '__size' refers to type 0x10baf04d which extends beyond the bounds of 0x10baefae</b></div><div>(facebook::biggrep::BigGrepMasterAsync *) this = 0x00007fd14d374fd0</div><div>(const string &const) corpus = error: summary string parsing error: {</div><div> store_ = {</div><div> = {</div><div> small_ = {}</div><div> <b>ml_ = (data_ = "��UH\x89�H�}�H\x8bE�]ÐUH\x89�H��H\x89}�H\x8bE�H\x89��~\xb4��\x90��UH\x89�SH\x83�H\x89}�H�u�H�E�H���\x9e���H\x8b\x18H\x8bE�H���O\xb4��H\x89ƿ\b", size_ = 0, capacity_ = 1441151880758558720)</b></div><div> }</div><div> }</div><div>}</div><div><b>(const string &const) needle = error: summary string parsing error: {</b></div><div> store_ = {</div><div> = {</div><div> small_ = {}</div><div> ml_ = (data_ = "", size_ = 0, capacity_ = 1080863910568919040)</div><div> }</div><div> }</div><div>}</div><div>(facebook::biggrep::Options &) options = 0x00007fd133cfb7b0: {</div><div> engine = error: summary string parsing error</div><div> full_lines = true</div><div> user = error: summary string parsing error</div><div> max_bytes = 5000000</div><div> leading_context = 0</div><div> trailing_context = 0</div><div> case_sensitive = true</div><div> client_hostname = error: summary string parsing error</div><div> client_ip = error: summary string parsing error</div><div> skip_logging = false</div><div> client_port = 0</div><div> shards_override = 0</div><div> sample = false</div><div> count = false</div><div> filename_pattern = error: summary string parsing error</div><div> limit = 0</div><div> __isset = {</div><div> engine = true</div><div> full_lines = true</div><div> user = true</div><div> max_bytes = true</div><div> leading_context = true</div><div> trailing_context = true</div><div> case_sensitive = true</div><div> client_hostname = true</div><div> client_ip = true</div><div> skip_logging = true</div><div> client_port = true</div><div> shards_override = true</div><div> sample = true</div><div> count = true</div><div> filename_pattern = true</div><div> limit = true</div><div> }</div><div>}</div><div>(size_t) recv_timeout = 140536468041728</div><div>(std::vector<std::basic_fbstring<char, std::char_traits<char>, std::allocator<char>, std::fbstring_core<char> >, std::allocator<std::basic_fbstring<char, std::char_traits<char>, std::allocator<char>, std::fbstring_core<char> > > >) corpuses = size=0 {}</div><div>(std::vector<facebook::biggrep::BigGrepMasterAsync::Revision, std::allocator<facebook::biggrep::BigGrepMasterAsync::Revision> >) revisions = size=0 {}</div><div>(std::vector<facebook::biggrep::BigGrepMasterAsync::RevisionShard, std::allocator<facebook::biggrep::BigGrepMasterAsync::RevisionShard> >) shards = size=0 {}</div><div><b>(std::string) returnRev = error: summary string parsing error</b></div><div>(<lambda(folly::StringPiece)>) quote = {}</div><div>(std::basic_fbstring<char, std::char_traits<char>, std::allocator<char>, std::fbstring_core<char> >) desc = {</div><div> store_ = {</div><div> = {</div><div> small_ = {}</div><div> ml_ = (data_ = "", size_ = 73415312, capacity_ = 140536494141696)</div><div> }</div><div> }</div><div>}</div><div>(folly::EventBase *) eb = 0x00007fd133cfb888</div><div>(apache::thrift::concurrency::ThreadManager *) tm = 0x00007fd133cfb570</div></div></div><div><br></div><div>I suspect each one may be different root cause. I was able to capture one callstack of a small repro:</div><div><br></div><div>Breakpoint 1, DWARFASTParserClang::ParseChildMembers (this=0x8c4520, sc=..., parent_die=..., class_clang_type=..., class_language=lldb::eLanguageTypeUnknown,<br></div><div><div> base_classes=..., member_accessibilities=..., member_function_dies=..., delayed_properties=...,</div><div> default_accessibility=@0x7ffdf3888cac: lldb::eAccessPublic, is_a_class=@0x7ffdf3888cab: false, layout_info=...)</div><div> at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2937</div><div>2937<span style="white-space:pre-wrap"> </span> parent_die.GetID());</div><div>(gdb) bt</div><div>#0 0x00007f103d02533d in DWARFASTParserClang::ParseChildMembers(lldb_private::SymbolContext const&, DWARFDIE const&, lldb_private::CompilerType&, lldb::LanguageType, std::vector<clang::CXXBaseSpecifier*, std::allocator<clang::CXXBaseSpecifier*> >&, std::vector<int, std::allocator<int> >&, DWARFDIECollection&, std::vector<DWARFASTParserClang::DelayedAddObjCClassProperty, std::allocator<DWARFASTParserClang::DelayedAddObjCClassProperty> >&, lldb::AccessType&, bool&, DWARFASTParserClang::LayoutInfo&) (this=0x8c4520, sc=..., parent_die=..., class_clang_type=..., class_language=lldb::eLanguageTypeUnknown, base_classes=..., member_accessibilities=..., member_function_dies=..., delayed_properties=..., default_accessibility=@0x7ffdf3888cac: lldb::eAccessPublic, is_a_class=@0x7ffdf3888cab: false, layout_info=...) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2937</div><div>#1 0x00007f103d025b84 in DWARFASTParserClang::CompleteTypeFromDWARF(DWARFDIE const&, lldb_private::Type*, lldb_private::CompilerType&) (this=0x8c4520, die=..., type=0xc40a50, clang_type=...)</div><div> at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2036</div><div>#2 0x00007f103d04c5e8 in SymbolFileDWARF::CompleteType(lldb_private::CompilerType&) (this=<optimized out>, compiler_type=...)</div><div> at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1635</div><div>#3 0x00007f103ceff9da in lldb_private::ClangASTContext::CompleteTagDecl(void*, clang::TagDecl*) (baton=<optimized out>, decl=0xc41bc0)</div><div> at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/ClangASTContext.cpp:9619</div><div>#4 0x00007f103cf03400 in GetCompleteQualType(clang::ASTContext*, clang::QualType, bool) (ast=0x7f102c020c30, qual_type=..., allow_completion=allow_completion@entry=true) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/ClangASTContext.cpp:2632</div><div>#5 0x00007f103cf0c99e in lldb_private::ClangASTContext::GetNumChildren(void*, bool) (this=0x8c43c0, type=<optimized out>, omit_empty_base_classes=<optimized out>) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/ClangASTContext.cpp:5067</div><div>#6 0x00007f103ce876ad in lldb_private::ValueObjectVariable::CalculateNumChildren(unsigned int) (this=<optimized out>, max=4294967295)</div><div> at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ValueObjectVariable.cpp:102</div><div>#7 0x00007f103ce7759f in lldb_private::ValueObject::GetNumChildren(unsigned int) (this=0xc40600, max=4294967295)</div><div> at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ValueObject.cpp:778</div><div>#8 0x00007f103cd999bd in lldb_private::FormatManager::ShouldPrintAsOneLiner(lldb_private::ValueObject&) (this=this@entry=0x7f103fe2f300 <GetFormatManager()::g_format_manager>, valobj=...) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/DataFormatters/FormatManager.cpp:576</div><div>#9 0x00007f103cd9226a in lldb_private::DataVisualization::ShouldPrintAsOneLiner(lldb_private::ValueObject&) (valobj=...)</div><div> at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/DataFormatters/DataVisualization.cpp:42</div><div>#10 0x00007f103cdc2167 in lldb_private::ValueObjectPrinter::PrintChildrenIfNeeded(bool, bool) (this=this@entry=0x7ffdf38892a0, value_printed=<optimized out>, summary_printed=<optimized out>) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/DataFormatters/ValueObjectPrinter.cpp:869</div><div>#11 0x00007f103cdc1572 in lldb_private::ValueObjectPrinter::PrintValueObject() (this=this@entry=0x7ffdf38892a0)</div><div> at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/DataFormatters/ValueObjectPrinter.cpp:111</div><div>#12 0x00007f103ce7102f in lldb_private::ValueObject::Dump(lldb_private::Stream&, lldb_private::DumpValueObjectOptions const&) (this=this@entry=0xc40600, s=..., options=...) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ValueObject.cpp:3585</div><div>#13 0x00007f103d27e5e4 in CommandObjectFrameVariable::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) (this=0x7d0590, command=..., result=...) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Commands/CommandObjectFrame.cpp:591</div><div>#14 0x00007f103cece45d in lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) (this=0x7d0590, args_string=<optimized out>, result=...) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Interpreter/CommandObject.cpp:1095</div><div>#15 0x00007f103cec9559 in lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, lldb_private::ExecutionContext*, bool, bool) (this=this@entry=0x7a5210, command_line=<optimized out>, lazy_add_to_history=lazy_add_to_history@entry=lldb_private::eLazyBoolCalculate, result=..., override_context=override_context@entry=0x0, repeat_on_empty_command=repeat_on_empty_command@entry=true, no_context_switching=false)</div><div> at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:1820</div><div>#16 0x00007f103ceca50d in lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::string&) (this=0x7a5210, io_handler=..., line=...) at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:2976</div><div>#17 0x00007f103ce1c733 in lldb_private::IOHandlerEditline::Run() (this=0x87d9b0)</div><div> at /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/IOHandler.cpp:736</div></div><div><br></div><div><br></div><div>Really appreciate if there is any fix/workaround I can get over this issue and unblock us!</div><div><br></div><div>Jeffrey</div></div>
<br></div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>