Jeffrey Tan via llvm-dev
2016-Mar-27 06:31 UTC
[llvm-dev] DW_TAG_member extends beyond the bounds error on Linux
Thanks David. I meant to send to lldb maillist, but glad to hear response here. Our binary is built from gcc: String dump of section '.comment': [ 1] GCC: (GNU) 4.9.x-google 20150123 (prerelease) Is there any similar flags we should use? By doing "strings -a [binary] | grep -i gcc", I found the following flags being used: 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 Also, per reading https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Debugging-Options.html, seems that we should use "-gdwarf-2" 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. Btw: I tried gdb against the same binary which seems to get better result: (gdb) p corpus $3 = (const std::string &) @0x7fd133cfb888: { static npos = 18446744073709551615, store_ = { static kIsLittleEndian = <optimized out>, static kIsBigEndian = <optimized out>, { small_ = "www", '\000' <repeats 20 times>, "\024", ml_ = { 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, capacity_ = 1441151880758558720}}}} Jeffrey On Sat, Mar 26, 2016 at 8:22 PM, David Blaikie <dblaikie at gmail.com> wrote:> 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) > > Not sure if that is the problem you are seeing, but will be a problem > sooner or later > On Mar 26, 2016 4:16 PM, "Jeffrey Tan via llvm-dev" < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> 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? >> >> Here is one example: >> >> (lldb) fr v >> *error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member >> '_M_pod_data' refers to type 0x10bb1e99 which extends beyond the bounds of >> 0x10b9a901* >> *error: biggrep_master_server_async 0x10b98edc: DW_TAG_member 'small_' >> refers to type 0x10bb1d9f which extends beyond the bounds of 0x10b98ed3* >> *error: biggrep_master_server_async 0x10baf034: DW_TAG_member '__size' >> refers to type 0x10baf04d which extends beyond the bounds of 0x10baefae* >> (facebook::biggrep::BigGrepMasterAsync *) this = 0x00007fd14d374fd0 >> (const string &const) corpus = error: summary string parsing error: { >> store_ = { >> = { >> small_ = {} >> *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)* >> } >> } >> } >> *(const string &const) needle = error: summary string parsing error: {* >> store_ = { >> = { >> small_ = {} >> ml_ = (data_ = "", size_ = 0, capacity_ = 1080863910568919040) >> } >> } >> } >> (facebook::biggrep::Options &) options = 0x00007fd133cfb7b0: { >> engine = error: summary string parsing error >> full_lines = true >> user = error: summary string parsing error >> max_bytes = 5000000 >> leading_context = 0 >> trailing_context = 0 >> case_sensitive = true >> client_hostname = error: summary string parsing error >> client_ip = error: summary string parsing error >> skip_logging = false >> client_port = 0 >> shards_override = 0 >> sample = false >> count = false >> filename_pattern = error: summary string parsing error >> limit = 0 >> __isset = { >> engine = true >> full_lines = true >> user = true >> max_bytes = true >> leading_context = true >> trailing_context = true >> case_sensitive = true >> client_hostname = true >> client_ip = true >> skip_logging = true >> client_port = true >> shards_override = true >> sample = true >> count = true >> filename_pattern = true >> limit = true >> } >> } >> (size_t) recv_timeout = 140536468041728 >> (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 {} >> (std::vector<facebook::biggrep::BigGrepMasterAsync::Revision, >> std::allocator<facebook::biggrep::BigGrepMasterAsync::Revision> >) >> revisions = size=0 {} >> (std::vector<facebook::biggrep::BigGrepMasterAsync::RevisionShard, >> std::allocator<facebook::biggrep::BigGrepMasterAsync::RevisionShard> >) >> shards = size=0 {} >> *(std::string) returnRev = error: summary string parsing error* >> (<lambda(folly::StringPiece)>) quote = {} >> (std::basic_fbstring<char, std::char_traits<char>, std::allocator<char>, >> std::fbstring_core<char> >) desc = { >> store_ = { >> = { >> small_ = {} >> ml_ = (data_ = "", size_ = 73415312, capacity_ = 140536494141696) >> } >> } >> } >> (folly::EventBase *) eb = 0x00007fd133cfb888 >> (apache::thrift::concurrency::ThreadManager *) tm = 0x00007fd133cfb570 >> >> I suspect each one may be different root cause. I was able to capture one >> callstack of a small repro: >> >> Breakpoint 1, DWARFASTParserClang::ParseChildMembers (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 >> 2937 >> parent_die.GetID()); >> (gdb) bt >> #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 >> #1 0x00007f103d025b84 in >> DWARFASTParserClang::CompleteTypeFromDWARF(DWARFDIE const&, >> lldb_private::Type*, lldb_private::CompilerType&) (this=0x8c4520, die=..., >> type=0xc40a50, clang_type=...) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2036 >> #2 0x00007f103d04c5e8 in >> SymbolFileDWARF::CompleteType(lldb_private::CompilerType&) (this=<optimized >> out>, compiler_type=...) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1635 >> #3 0x00007f103ceff9da in >> lldb_private::ClangASTContext::CompleteTagDecl(void*, clang::TagDecl*) >> (baton=<optimized out>, decl=0xc41bc0) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/ClangASTContext.cpp:9619 >> #4 0x00007f103cf03400 in GetCompleteQualType(clang::ASTContext*, >> clang::QualType, bool) (ast=0x7f102c020c30, qual_type=..., >> allow_completion=allow_completion at entry=true) at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/ClangASTContext.cpp:2632 >> #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 >> #6 0x00007f103ce876ad in >> lldb_private::ValueObjectVariable::CalculateNumChildren(unsigned int) >> (this=<optimized out>, max=4294967295) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ValueObjectVariable.cpp:102 >> #7 0x00007f103ce7759f in >> lldb_private::ValueObject::GetNumChildren(unsigned int) (this=0xc40600, >> max=4294967295) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ValueObject.cpp:778 >> #8 0x00007f103cd999bd in >> lldb_private::FormatManager::ShouldPrintAsOneLiner(lldb_private::ValueObject&) >> (this=this at 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 >> #9 0x00007f103cd9226a in >> lldb_private::DataVisualization::ShouldPrintAsOneLiner(lldb_private::ValueObject&) >> (valobj=...) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/DataFormatters/DataVisualization.cpp:42 >> #10 0x00007f103cdc2167 in >> lldb_private::ValueObjectPrinter::PrintChildrenIfNeeded(bool, bool) >> (this=this at 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 >> #11 0x00007f103cdc1572 in >> lldb_private::ValueObjectPrinter::PrintValueObject() (this=this at entry >> =0x7ffdf38892a0) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/DataFormatters/ValueObjectPrinter.cpp:111 >> #12 0x00007f103ce7102f in >> lldb_private::ValueObject::Dump(lldb_private::Stream&, >> lldb_private::DumpValueObjectOptions const&) (this=this at entry=0xc40600, >> s=..., options=...) at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ValueObject.cpp:3585 >> #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 >> #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 >> #15 0x00007f103cec9559 in >> lldb_private::CommandInterpreter::HandleCommand(char const*, >> lldb_private::LazyBool, lldb_private::CommandReturnObject&, >> lldb_private::ExecutionContext*, bool, bool) (this=this at entry=0x7a5210, >> command_line=<optimized out>, lazy_add_to_history=lazy_add_to_history at entry=lldb_private::eLazyBoolCalculate, >> result=..., override_context=override_context at entry=0x0, >> repeat_on_empty_command=repeat_on_empty_command at entry=true, >> no_context_switching=false) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:1820 >> #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 >> #17 0x00007f103ce1c733 in lldb_private::IOHandlerEditline::Run() >> (this=0x87d9b0) >> at >> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/IOHandler.cpp:736 >> >> >> Really appreciate if there is any fix/workaround I can get over this >> issue and unblock us! >> >> Jeffrey >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160326/d125dfe4/attachment.html>
David Blaikie via llvm-dev
2016-Mar-27 15:58 UTC
[llvm-dev] DW_TAG_member extends beyond the bounds error on Linux
On Sat, Mar 26, 2016 at 11:31 PM, Jeffrey Tan <jeffrey.fudan at gmail.com> wrote:> Thanks David. I meant to send to lldb maillist, but glad to hear response > here. > > Our binary is built from gcc: > String dump of section '.comment': > [ 1] GCC: (GNU) 4.9.x-google 20150123 (prerelease) > > Is there any similar flags we should use? >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 -femit-class-debug-always with GCC 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) that produces the problem)> By doing "strings -a [binary] | grep -i gcc", I found the following flags > being used: > 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 > > Also, per reading > https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Debugging-Options.html, > seems that we should use "-gdwarf-2" 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. > > Btw: I tried gdb against the same binary which seems to get better result: > > (gdb) p corpus > $3 = (const std::string &) @0x7fd133cfb888: { > static npos = 18446744073709551615, store_ = { > static kIsLittleEndian = <optimized out>, > static kIsBigEndian = <optimized out>, { > small_ = "www", '\000' <repeats 20 times>, "\024", ml_ = { > 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, > capacity_ = 1441151880758558720}}}} > > Jeffrey > > > > On Sat, Mar 26, 2016 at 8:22 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> 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) >> >> Not sure if that is the problem you are seeing, but will be a problem >> sooner or later >> On Mar 26, 2016 4:16 PM, "Jeffrey Tan via llvm-dev" < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi, >>> >>> 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? >>> >>> Here is one example: >>> >>> (lldb) fr v >>> *error: biggrep_master_server_async 0x10b9a91a: DW_TAG_member >>> '_M_pod_data' refers to type 0x10bb1e99 which extends beyond the bounds of >>> 0x10b9a901* >>> *error: biggrep_master_server_async 0x10b98edc: DW_TAG_member 'small_' >>> refers to type 0x10bb1d9f which extends beyond the bounds of 0x10b98ed3* >>> *error: biggrep_master_server_async 0x10baf034: DW_TAG_member '__size' >>> refers to type 0x10baf04d which extends beyond the bounds of 0x10baefae* >>> (facebook::biggrep::BigGrepMasterAsync *) this = 0x00007fd14d374fd0 >>> (const string &const) corpus = error: summary string parsing error: { >>> store_ = { >>> = { >>> small_ = {} >>> *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)* >>> } >>> } >>> } >>> *(const string &const) needle = error: summary string parsing error: {* >>> store_ = { >>> = { >>> small_ = {} >>> ml_ = (data_ = "", size_ = 0, capacity_ = 1080863910568919040) >>> } >>> } >>> } >>> (facebook::biggrep::Options &) options = 0x00007fd133cfb7b0: { >>> engine = error: summary string parsing error >>> full_lines = true >>> user = error: summary string parsing error >>> max_bytes = 5000000 >>> leading_context = 0 >>> trailing_context = 0 >>> case_sensitive = true >>> client_hostname = error: summary string parsing error >>> client_ip = error: summary string parsing error >>> skip_logging = false >>> client_port = 0 >>> shards_override = 0 >>> sample = false >>> count = false >>> filename_pattern = error: summary string parsing error >>> limit = 0 >>> __isset = { >>> engine = true >>> full_lines = true >>> user = true >>> max_bytes = true >>> leading_context = true >>> trailing_context = true >>> case_sensitive = true >>> client_hostname = true >>> client_ip = true >>> skip_logging = true >>> client_port = true >>> shards_override = true >>> sample = true >>> count = true >>> filename_pattern = true >>> limit = true >>> } >>> } >>> (size_t) recv_timeout = 140536468041728 >>> (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 {} >>> (std::vector<facebook::biggrep::BigGrepMasterAsync::Revision, >>> std::allocator<facebook::biggrep::BigGrepMasterAsync::Revision> >) >>> revisions = size=0 {} >>> (std::vector<facebook::biggrep::BigGrepMasterAsync::RevisionShard, >>> std::allocator<facebook::biggrep::BigGrepMasterAsync::RevisionShard> >) >>> shards = size=0 {} >>> *(std::string) returnRev = error: summary string parsing error* >>> (<lambda(folly::StringPiece)>) quote = {} >>> (std::basic_fbstring<char, std::char_traits<char>, std::allocator<char>, >>> std::fbstring_core<char> >) desc = { >>> store_ = { >>> = { >>> small_ = {} >>> ml_ = (data_ = "", size_ = 73415312, capacity_ = 140536494141696) >>> } >>> } >>> } >>> (folly::EventBase *) eb = 0x00007fd133cfb888 >>> (apache::thrift::concurrency::ThreadManager *) tm = 0x00007fd133cfb570 >>> >>> I suspect each one may be different root cause. I was able to capture >>> one callstack of a small repro: >>> >>> Breakpoint 1, DWARFASTParserClang::ParseChildMembers (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 >>> 2937 >>> parent_die.GetID()); >>> (gdb) bt >>> #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 >>> #1 0x00007f103d025b84 in >>> DWARFASTParserClang::CompleteTypeFromDWARF(DWARFDIE const&, >>> lldb_private::Type*, lldb_private::CompilerType&) (this=0x8c4520, die=..., >>> type=0xc40a50, clang_type=...) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2036 >>> #2 0x00007f103d04c5e8 in >>> SymbolFileDWARF::CompleteType(lldb_private::CompilerType&) (this=<optimized >>> out>, compiler_type=...) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:1635 >>> #3 0x00007f103ceff9da in >>> lldb_private::ClangASTContext::CompleteTagDecl(void*, clang::TagDecl*) >>> (baton=<optimized out>, decl=0xc41bc0) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/ClangASTContext.cpp:9619 >>> #4 0x00007f103cf03400 in GetCompleteQualType(clang::ASTContext*, >>> clang::QualType, bool) (ast=0x7f102c020c30, qual_type=..., >>> allow_completion=allow_completion at entry=true) at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Symbol/ClangASTContext.cpp:2632 >>> #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 >>> #6 0x00007f103ce876ad in >>> lldb_private::ValueObjectVariable::CalculateNumChildren(unsigned int) >>> (this=<optimized out>, max=4294967295) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ValueObjectVariable.cpp:102 >>> #7 0x00007f103ce7759f in >>> lldb_private::ValueObject::GetNumChildren(unsigned int) (this=0xc40600, >>> max=4294967295) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ValueObject.cpp:778 >>> #8 0x00007f103cd999bd in >>> lldb_private::FormatManager::ShouldPrintAsOneLiner(lldb_private::ValueObject&) >>> (this=this at 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 >>> #9 0x00007f103cd9226a in >>> lldb_private::DataVisualization::ShouldPrintAsOneLiner(lldb_private::ValueObject&) >>> (valobj=...) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/DataFormatters/DataVisualization.cpp:42 >>> #10 0x00007f103cdc2167 in >>> lldb_private::ValueObjectPrinter::PrintChildrenIfNeeded(bool, bool) >>> (this=this at 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 >>> #11 0x00007f103cdc1572 in >>> lldb_private::ValueObjectPrinter::PrintValueObject() (this=this at entry >>> =0x7ffdf38892a0) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/DataFormatters/ValueObjectPrinter.cpp:111 >>> #12 0x00007f103ce7102f in >>> lldb_private::ValueObject::Dump(lldb_private::Stream&, >>> lldb_private::DumpValueObjectOptions const&) (this=this at entry=0xc40600, >>> s=..., options=...) at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/ValueObject.cpp:3585 >>> #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 >>> #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 >>> #15 0x00007f103cec9559 in >>> lldb_private::CommandInterpreter::HandleCommand(char const*, >>> lldb_private::LazyBool, lldb_private::CommandReturnObject&, >>> lldb_private::ExecutionContext*, bool, bool) (this=this at entry=0x7a5210, >>> command_line=<optimized out>, lazy_add_to_history=lazy_add_to_history at entry=lldb_private::eLazyBoolCalculate, >>> result=..., override_context=override_context at entry=0x0, >>> repeat_on_empty_command=repeat_on_empty_command at entry=true, >>> no_context_switching=false) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Interpreter/CommandInterpreter.cpp:1820 >>> #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 >>> #17 0x00007f103ce1c733 in lldb_private::IOHandlerEditline::Run() >>> (this=0x87d9b0) >>> at >>> /home/engshare/third-party2/lldb/3.8.0.rc3/src/llvm/tools/lldb/source/Core/IOHandler.cpp:736 >>> >>> >>> Really appreciate if there is any fix/workaround I can get over this >>> issue and unblock us! >>> >>> Jeffrey >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160327/799858ea/attachment.html>
Maybe Matching Threads
- DW_TAG_member extends beyond the bounds error on Linux
- DW_TAG_member extends beyond the bounds error on Linux
- DW_TAG_member extends beyond the bounds error on Linux
- [LLVMdev] CMake does not propagate flags to build
- [LLVMdev] CMake does not propagate flags to build