date:20160327

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

2016-03-27 Thread Siva Chandra via lldb-dev

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 ) 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

2016-03-27 Thread Eran Ifrah via lldb-dev

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

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

2016-03-27 Thread Jeffrey Tan via lldb-dev

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 )#1},
void>::type::value_type
folly::fibers::await)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
folly::fibers::FirstArgOf)#1},
void>::type::value_type
folly::fibers::await)#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 ) 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] [llvm-dev] DW_TAG_member extends beyond the bounds error on Linux

2016-03-27 Thread David Blaikie via lldb-dev

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 )#1},
> void>::type::value_type
> folly::fibers::await)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
> folly::fibers::FirstArgOf)#1},
> void>::type::value_type
> folly::fibers::await)#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

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

2016-03-27 Thread Jeffrey Tan via lldb-dev

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 ) 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)
}
  }
}

Thanks for any info regarding how to encode this string.

Jeffrey

On Sat, Mar 26, 2016 at 3:34 PM, Jeffrey Tan 
wrote:

> Follow-up for the previous question:
>
> Our python code is trying to call json.dumps to serialize the variable
> evaluation result into string block and send to IDE via RPC, however it
> failed with "UnicodeDecodeError: 'utf8' codec can't decode byte 0xc9 in
> position 10: invalid continuation byte" because SBValue.description seems
> to return non-utf-8 string:
>
> (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 ) 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)*
> }
>   }
> }
>
>
> File
> "/data/users/jeffreytan/fbsource/fbobjc/Tools/Nuclide/pkg/nuclide-debugger-lldb-server/scripts/chromedebugger.py",
> line 91, in received_message
> *response_in_json = json.dumps(response);*
>   File "/usr/lib64/python2.6/json/__init__.py", line 230, in dumps
> return _default_encoder.encode(obj)
>   File "/usr/lib64/python2.6/json/encoder.py", line 367, in encode
> chunks = list(self.iterencode(o))
>   File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
> for chunk in self._iterencode_dict(o, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 275, in
> _iterencode_dict
> for chunk in self._iterencode(value, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
> for chunk in self._iterencode_dict(o, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 275, in
> _iterencode_dict
> for chunk in self._iterencode(value, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 306, in _iterencode
> for chunk in self._iterencode_list(o, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 204, in
> _iterencode_list
> for chunk in self._iterencode(value, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
> for chunk in self._iterencode_dict(o, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 275, in
> _iterencode_dict
> for chunk in self._iterencode(value, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 309, in _iterencode
> for chunk in self._iterencode_dict(o, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 275, in
> _iterencode_dict
> for chunk in self._iterencode(value, markers):
>   File "/usr/lib64/python2.6/json/encoder.py", line 294, in _iterencode
> yield encoder(o)
> *UnicodeDecodeError: 'utf8' codec can't decode byte 0xc9 in position 10:
> invalid continuation byte*
>
> Question:
> Is the non utf-8 string expected or just gabage data because of the 
> DW_TAG_member
> error? What is the proper way find out the string encoding and serialize
> using* json.dumps()*?
>
> Jeffrey
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] DW_TAG_member extends beyond the bounds error on Linux

2016-03-27 Thread Jeffrey Tan via lldb-dev

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 = ,
static kIsBigEndian = , {
  small_ = "www", '\000' , "\024", ml_ = {
data_ = 0x77 )#1},
void>::type::value_type
folly::fibers::await)#1}>(folly::fibers::FirstArgOf&&)::{lambda()#1}>(folly::fibers::FiberManager&,
folly::fibers::FirstArgOf)#1},
void>::type::value_type
folly::fibers::await)#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 ) 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 ) needle = error: summary string parsing error: {*
>>   store_ = {
>>  = {
>>   small_ = {}
>>   ml_ = (data_ = "", size_

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

[lldb-dev] LLDB /w Windows and MinGW64

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

Re: [lldb-dev] [llvm-dev] DW_TAG_member extends beyond the bounds error on Linux

Re: [lldb-dev] UnicodeDecodeError for serialize SBValue description

Re: [lldb-dev] [llvm-dev] DW_TAG_member extends beyond the bounds error on Linux

6 matches

Site Navigation

Mail list logo

Footer information