Re: [lldb-dev] [llvm-dev] DW_TAG_member extends beyond the bounds error on Linux
On Sat, Mar 26, 2016 at 11:31 PM, Jeffrey Tan
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 = ,
> static kIsBigEndian = , {
> small_ = "www", '\000' , "\024", ml_ = {
> data_ = 0x77 folly::fibers::Baton::waitFiber::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
> void>::type::value_type
> folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
> folly::fibers::FirstArgOf::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
> void>::type::value_type
> folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::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 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-...@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 = 0x7fd14d374fd0
>>> (const string &const) corpus = error: summary string parsing error: {
>>> store_ = {
>>> = {
>>> small_ = {}
>>> *ml_ = (data_ =
>>> "��UH\x8
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
Thanks Siva. All the *DW_TAG_member *related errors seems to go away after
patching with your fix. The current problem is handling the decoding.
Here is the correct decoding from gdb whic might be useful:
(gdb) p corpus
$3 = (const std::string &) @0x7fd133cfb888: {
static npos = 18446744073709551615, store_ = {
static kIsLittleEndian = ,
static kIsBigEndian = , {
small_ = "www", '\000' , "\024", ml_ = {
data_ = 0x77 ::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
void>::type::value_type
folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
folly::fibers::FirstArgOf::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::prepareForSelection(facebook::servicerouter::DispatchContext&)::SelectionResult>)#1},
void>::type::value_type
folly::fibers::await::prepareForSelection(facebook::servicerouter::DispatchContext&)::{lambda(folly::fibers::Promise::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
Utf-16 does not seem to decode it, while 'latin-1' does:
>>> '\xc9'.decode('utf-16')
Traceback (most recent call last):
File "", line 1, in
File
"/mnt/gvfs/third-party2/python/55c1fd79d91c77c95932db31a4769919611c12bb/2.7.8/centos6-native/da39a3e/lib/python2.7/encodings/utf_16.py",
line 16, in decode
return codecs.utf_16_decode(input, errors, True)
UnicodeDecodeError: 'utf16' codec can't decode byte 0xc9 in position 0:
truncated data
>>> '\xc9'.decode('latin-1')
u'\xc9'
Instead of guessing what kind of decoding I should use, I would use
'ensure_ascii=False' to prevent the crash for now.
I tried to reproduce this crash, but it seems that the crash might be
related with some internal stl implementation we are using. I will see if I
can narrow down to a small repro later.
Thanks
Jeffrey
On Sun, Mar 27, 2016 at 2:49 PM, Siva Chandra wrote:
> On Sat, Mar 26, 2016 at 11:58 PM, Jeffrey Tan
> wrote:
> > Btw: after patching with Siva's fix http://reviews.llvm.org/D18008, the
> > first field 'small_' is fixed, however the second field 'ml_' still emits
> > garbage:
> >
> > (lldb) fr v corpus
> > (const string &const) corpus = error: summary string parsing error: {
> > store_ = {
> > = {
> > small_ = "www"
> > 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)
> > }
> > }
> > }
>
> Do you still see the DW_TAG_member related error?
>
> A wild (and really wild at that) guess: Is it utf16 data that is being
> decoded as utf8?
>
> As David Blaikie mentioned on the other thread, it would really help
> if you provide us with a minimal example to repro this. Atleast, repro
> instructions.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description
On Sat, Mar 26, 2016 at 11:58 PM, Jeffrey Tan wrote:
> Btw: after patching with Siva's fix http://reviews.llvm.org/D18008, the
> first field 'small_' is fixed, however the second field 'ml_' still emits
> garbage:
>
> (lldb) fr v corpus
> (const string &const) corpus = error: summary string parsing error: {
> store_ = {
> = {
> small_ = "www"
> 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)
> }
> }
> }
Do you still see the DW_TAG_member related error?
A wild (and really wild at that) guess: Is it utf16 data that is being
decoded as utf8?
As David Blaikie mentioned on the other thread, it would really help
if you provide us with a minimal example to repro this. Atleast, repro
instructions.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLDB /w Windows and MinGW64
Hi, I have built LLDB on Windows 7 using MinGW64/4.9.2 (took some effort to get the job done...) When I tried to debug a simple hello world executable, I get this output: D:\software\msys-for-clang\1.0\home\PC\build-release-64-lldb\bin>lldb.exe HelloWorld.exe (lldb) target create "HelloWorld.exe" Current executable set to 'HelloWorld.exe' (x86_64). (lldb) b main.cpp:7 Breakpoint 1: where = HelloWorld.exe`main + 26 at main.cpp:7, address = 0x0040154a (lldb) r error: process launch failed: unable to locate lldb-server (lldb) I can't seem to locate lldb-server anywhere, and according to LLDBConfig.cmake, this target should not get built on Windows: # Figure out if lldb could use lldb-server. If so, then we'll # ensure we build lldb-server when an lldb target is being built. if ((CMAKE_SYSTEM_NAME MATCHES "Darwin") OR (CMAKE_SYSTEM_NAME MATCHES "FreeBSD") OR (CMAKE_SYSTEM_NAME MATCHES "Linux") OR (CMAKE_SYSTEM_NAME MATCHES "NetBSD")) set(LLDB_CAN_USE_LLDB_SERVER 1) else() set(LLDB_CAN_USE_LLDB_SERVER 0) endif() and in the tools/CMakeLists.txt file we have this: if (LLDB_CAN_USE_LLDB_SERVER) add_subdirectory(lldb-server) endif() Any ideas? Thanks, -- Eran Ifrah, Author of CodeLite , a cross platform open source C/C++ IDE: http://www.codelite.org CodeLite IDE Blog: http://codeliteide.blogspot.com/ ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
