[lldb-dev] UnicodeDecodeError for serialize SBValue description
Jeffrey Tan via lldb-dev
lldb-dev at lists.llvm.org
Sat Apr 30 13:14:03 PDT 2016
Hi Enrico/Greg,
Can you help me to understand what is the difference between "p" and "fr v"
command to print local variables? My data formatter works fine in all cases
of "fr v", and will fail for "p" command in some case(implementation at the
end). In the debug log output below, you can see, when I use "fr v" command
the "char[24]" object is summarized correctly, while "p" command fail to
recognize it. I suspect "char32_t [] summary provider" may have failed in
"p" case, but could not understand why.
(lldb) p small
folly_stl_string_formatter: $2 $2
folly_fbstring_core: store_ $2.store_ [115L, 109L, 97L, 108L, 108L, 0L, 0L,
0L, 235L, 46L, 64L, 0L, 0L, 0L, 0L, 0L, 80L, 213L, 255L, 255L, 255L, 127L,
0L, 18L]
category: 0
obj: (char [24]) small_ = {
[0] = 's'
[1] = 'm'
[2] = 'a'
[3] = 'l'
[4] = 'l'
[5] = '\0'
[6] = '\0'
[7] = '\0'
[8] = '\xeb'
[9] = '.'
[10] = '@'
[11] = '\0'
[12] = '\0'
[13] = '\0'
[14] = '\0'
[15] = '\0'
[16] = 'P'
[17] = '\xd5'
[18] = '\xff'
[19] = '\xff'
[20] = '\xff'
[21] = '\x7f'
[22] = '\0'
[23] = '\x12'
}, None, None
(std::string) $2 = None
(lldb) fr v small
folly_stl_string_formatter: small small
folly_fbstring_core: store_ small.store_ [115L, 109L, 97L, 108L, 108L, 0L,
0L, 0L, 235L, 46L, 64L, 0L, 0L, 0L, 0L, 0L, 80L, 213L, 255L, 255L, 255L,
127L, 0L, 18L]
category: 0
obj: (char [24]) small_ = "small", "small", None
(std::string) small = "small"
===============================
import lldb
target_byte_order = lldb.target.GetByteOrder()
def get_category_value(category_sbvalue, category_extract_mask):
return category_sbvalue.unsigned & category_extract_mask
def folly_stl_string_formatter(valobj, internal_dict):
'''Type summary formatter for std::string implemented by folly
fbstring_core.
'''
print 'folly_stl_string_formatter: %s %s' % (valobj.name, valobj.path)
folly_fbstring_sbvalue = valobj.GetValueForExpressionPath('.store_')
return folly_fbstring_core_formatter(folly_fbstring_sbvalue,
internal_dict)
def folly_fbstring_core_formatter(valobj, internal_dict):
'''Type summary formatter for folly fbstring_core.
Please refer to
https://github.com/facebook/folly/blob/master/folly/FBString.h
for implementation details.
'''
print 'folly_fbstring_core: %s %s %s' % (valobj.name, valobj.path,
str(valobj.data.uint8s))
capacity_sbvalue = valobj.GetValueForExpressionPath('.ml_.capacity_')
category_extract_mask = 0x3 if target_byte_order == lldb.eByteOrderBig
else \
(0xC0000000 if capacity_sbvalue.size == 4 else 0xC000000000000000)
class Category:
Small = 0
Medium = (0x2 if target_byte_order == lldb.eByteOrderBig else
(0x80000000 if capacity_sbvalue.size == 4 else
0x8000000000000000))
Large = (0x2 if target_byte_order == lldb.eByteOrderBig else
(0x40000000 if capacity_sbvalue.size == 4 else
0x4000000000000000))
category = get_category_value(capacity_sbvalue, category_extract_mask)
print 'category: %s' % category
if category == Category.Small:
obj = valobj.GetValueForExpressionPath('.small_')
print 'obj: %s, %s, %s' % (obj, obj.summary, obj.description)
return valobj.GetValueForExpressionPath('.small_').GetSummary()
else:
assert category == Category.Medium or category == Category.Large, \
'Unknown category: %d' % category
return valobj.GetValueForExpressionPath('.ml_.data_').GetSummary()
def __lldb_init_module(debugger, internal_dict):
debugger.HandleCommand('type summary add -F
data_formatter.folly_fbstring_core_formatter \
std::fbstring_core<char>')
debugger.HandleCommand('type summary add -F
data_formatter.folly_fbstring_core_formatter \
std::fbstring_core<wchar_t>')
debugger.HandleCommand('type summary add -F
data_formatter.folly_stl_string_formatter \
std::string')
debugger.HandleCommand('type summary add -F
data_formatter.folly_stl_string_formatter \
std::wstring')
On Wed, Apr 20, 2016 at 4:02 PM, Jeffrey Tan <jeffrey.fudan at gmail.com>
wrote:
> After removing the "-x" and apply the formatter to "std::string" instead
> of fbstring_core, it works fine now. Thanks!
>
> On Wed, Apr 20, 2016 at 3:24 PM, Enrico Granata <egranata at apple.com>
> wrote:
>
>>
>> On Apr 20, 2016, at 3:08 PM, Jeffrey Tan <jeffrey.fudan at gmail.com> wrote:
>>
>> Hi Enrico,
>>
>> Instead of trying function-evaluation c_str(), I decided to decode the
>> information from fbstring_core fields. I got it working but have two
>> questions for it.
>>
>> type summary add -F data_formatter.folly_string_formatter -x
>> "std::fbstring_core<char>"
>>
>> Here is the output:
>>
>> fr v -T small
>> (std::string) small = "small"
>>
>> fr v -T small.store_
>> (std::fbstring_core<char>) small.store_ = None
>>
>> fr v -T small.store_.ml_
>> (std::fbstring_core<char>::MediumLarge) small.store_.ml_ = None
>>
>> Questions:
>> 1. Even I only added formatter for std::fbstring_core<char> why does it
>> work for std::string?
>> 2. Why the later small.store_ and small.store_.ml_ will show summary None
>> now? I would not expect the data formatter will happen to them.
>>
>>
>> Using “-x” means you added a summary for every type that matches the
>> regular expression “std::fbstring_core<char>”
>> If you seriously only want to match “std::fbstring_core<char>”, you
>> should leave out the “-x” argument
>> That should solve the third problem you are running into
>>
>> As for the first issue - I am not sure - I’d need to look at the
>> data_formatter.py file
>>
>>
>> Btw: here is the implementation of fbstring_core
>> https://github.com/facebook/folly/blob/master/folly/FBString.h
>>
>> Thanks
>> Jeffrey
>>
>> On Wed, Apr 13, 2016 at 11:08 AM, Enrico Granata <egranata at apple.com>
>> wrote:
>>
>>> In theory what you're doing looks like it should be supported. I am not
>>> sure why your example is failing the way it is.
>>>
>>> Is your variable a global maybe?
>>>
>>> Also, using the variable name is the wrong thing to do. If you have a
>>> class with a std::string member, the name is going to return the wrong
>>> thing. You would want to at least use the expression path - and even then
>>> there are some cases where we can't cons up a proper expression path.
>>>
>>> Sent from my iPhone
>>>
>>> On Apr 13, 2016, at 11:02 AM, Jeffrey Tan <jeffrey.fudan at gmail.com>
>>> wrote:
>>>
>>> I did a quick testing to call
>>> SBFrame.EvaluateExpression('string.c_str()') for the summary. The result
>>> shows valobj.GetFrame() returns None so does this mean this is not
>>> supported?
>>>
>>> def DoTest(valobj,internal_dict):
>>> print "valobj: %s" % valobj
>>> print "valobj.GetFrame(): %s" % valobj.GetFrame()
>>> summaryValue = valobj.GetFrame().EvaluateExpression(valobj.name +
>>> '.c_str()')
>>> print "summaryValue: %s" % summaryValue
>>> return 'Summary from c_str(): %s ' % summaryValue.GetSummary()
>>>
>>> type summary add -F DoTest -x "std::fbstring_core<char>"
>>>
>>> Output:
>>> valobj.GetFrame(): No value
>>> summaryValue: No value
>>> valobj: (std::string) $6 = {
>>> store_ = Summary from c_str(): None
>>> }
>>>
>>> Jeffrey
>>>
>>> On Wed, Apr 13, 2016 at 10:11 AM, Jeffrey Tan <jeffrey.fudan at gmail.com>
>>> wrote:
>>>
>>>> One quick question: do we support getting type summary string from
>>>> inferior method call? After reading our own fbstring_core code, I found I
>>>> need to mirror a lot of what fbstring_core.c_str() method is doing in
>>>> python. I wonder if we can just call ${var.c_str()} as the type summary? I
>>>> suspect one of the concern is side-effect(the inferior method may throw
>>>> exception or cause problems) but I would not see why this can't be done. By
>>>> allowing this we can keep the data formatter truth one copy(in source code)
>>>> instead of potential out-of-sync(let say the std::string author decided to
>>>> change it implementation, the python data formatter associated with it
>>>> needs to be modified at the same time which is a maintain nightmare).
>>>>
>>>> Jeffrey
>>>>
>>>> On Thu, Apr 7, 2016 at 10:33 AM, Enrico Granata <egranata at apple.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Apr 6, 2016, at 7:31 PM, Jeffrey Tan <jeffrey.fudan at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Thanks Enrico. This is very detailed! I will take a look.
>>>>> Btw: originally, I was hoping that data formatter can be added without
>>>>> changing the source code. Like giving a xml/json format file telling lldb
>>>>> the memory layout/structure of the data structure, lldb can parse the
>>>>> xml/json and deduce the formatting. This is approach used by data
>>>>> visualizer in VS debugger:
>>>>> https://msdn.microsoft.com/en-us/library/jj620914.aspx
>>>>> This will make adding data formatter more extensible/flexible. Any
>>>>> reason we did not take this approach?
>>>>>
>>>>>
>>>>> The way I understand the Natvis system, it allows one to provide a
>>>>> bunch of expressions that describe how the debugger would go about
>>>>> retrieving the interesting data bits
>>>>> This has the bonus of being really easy, since you’re writing code in
>>>>> the same language/context of the types you’re formatting
>>>>> On the other hand it has a few drawbacks, in terms of performance as
>>>>> well as safety (imagine trying to run code on an object when said object is
>>>>> in an incoherent state)
>>>>> The LLDB approach, on the other hand, is that you should try to not
>>>>> run code when providing these data formatters. In order to do that, we vend
>>>>> an API that can do things such as retrieve child values, read memory, cast
>>>>> values, …, all without code execution
>>>>> Once you have this kind of API that is not expressed in your source
>>>>> language, you might just as well describe it in a scripting language. Hence
>>>>> were born the Python data formatters.
>>>>> In order for us to gain even more performance for native system types
>>>>> that we know we’re gonna run into all the time, we then switched a bunch of
>>>>> the “mission critical” formatters from Python to C++
>>>>> The Python extension points are still available, as Jim pointed out,
>>>>> and you are more than welcome to use those instead of modifying the
>>>>> debugger core
>>>>>
>>>>> Jeffrey
>>>>>
>>>>> On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata <egranata at apple.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Apr 5, 2016, at 2:42 PM, Jeffrey Tan <jeffrey.fudan at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Enrico,
>>>>>>
>>>>>> Any suggestion/example how to add a data formatter for our own STL
>>>>>> string? From the output below I can see we are using our own "
>>>>>> *fbstring_core*" which I assume I need to write a type summary for
>>>>>> this type:
>>>>>>
>>>>>> frame variable corpus -T
>>>>>> (const string &const) corpus = error: summary string parsing error: {
>>>>>> (std::*fbstring_core*<char>) store_ = {
>>>>>> (std::*fbstring_core*<char>::(anonymous union)) = {
>>>>>> (char [24]) small_ = "www"
>>>>>> (std::fbstring_core<char>::MediumLarge) ml_ = {
>>>>>> (char *) data_ = 0x0000000000777777
>>>>>> "H\x89U\xa8H\x89M\xa0L\x89E\x98H\x8bE\xa8H\x89��_U��D\x88e�H\x8bE\xa0H\x89��]U��H\x89�H\x8dE�H\x89�H\x89���
>>>>>> ��L\x8dm�H\x8bE\x98H\x89��IU��\x88]�L\x8be\xb0L\x89��
>>>>>> (std::size_t) size_ = 0
>>>>>> (std::size_t) capacity_ = 1441151880758558720
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Admittedly, this is going to be a little vague since I haven’t really
>>>>>> seen your code and I am only working off of one sample
>>>>>>
>>>>>> There’s going to be two parts to getting this to work:
>>>>>>
>>>>>> *Part 1 - Formatting fbstring_core*
>>>>>>
>>>>>> At a glance, an fbstring_core<char> can be backed by two
>>>>>> representations. A “small” representation (a char array), and a
>>>>>> “medium/large" representation (a char* + a size)
>>>>>> I assume that the way you tell one from the other is
>>>>>>
>>>>>> if (size == 0) small
>>>>>> else medium-large
>>>>>>
>>>>>> If my assumption is not correct, you’ll need to discover what the
>>>>>> correct discriminator logic is - the class has to know, and so do you :-)
>>>>>>
>>>>>> Armed with that knowledge, look in lldb
>>>>>> source/Plugins/Language/CPlusPlus/Formatters/LibCxx.cpp
>>>>>> There’s a bunch of code that deals with formatting llvm’s libc++
>>>>>> std::string - which follows a very similar logic to your class
>>>>>>
>>>>>> ExtractLibcxxStringInfo() is the function that handles discovering
>>>>>> which layout the string uses - where the data lives - and how much data
>>>>>> there is
>>>>>>
>>>>>> Once you have told yourself how much data there is (the size) and
>>>>>> where it lives (array or pointer), LibcxxStringSummaryProvider() has
>>>>>> the easy task - it sets up a StringPrinter, tells it how much data to
>>>>>> print, where to get it from, and then delegates the StringPrinter to do the
>>>>>> grunt work
>>>>>> StringPrinter is a nifty little tool - it can handle generating
>>>>>> summaries for different kinds of strings (UTF8? UTF16? we got it - is a \0
>>>>>> a terminator? what quote character would you like? …) - you point it at
>>>>>> some data, set up a few options, and it will generate a printable
>>>>>> representation for you - if your string type is doing anything out of the
>>>>>> ordinary, let’s talk - I am definitely open to extending StringPrinter to
>>>>>> handle even more magic
>>>>>>
>>>>>> *Part 2 - Teaching std::string that it can be backed by an
>>>>>> fbstring_core*
>>>>>>
>>>>>> At the end of part 1, you’ll probably end up with a
>>>>>> FBStringCoreSummaryProvider() - now you need to teach LLDB about it
>>>>>> The obvious thing you could do would be to go in CPlusPlusLanguage
>>>>>> ::GetFormatters() add a LoadFBStringFormatter(g_category) to it -
>>>>>> and then imitate - say - LoadLibCxxFormatters()
>>>>>>
>>>>>> AddCXXSummary(cpp_category_sp, lldb_private::formatters::
>>>>>> FBStringCoreSummaryProvider, “fbstringcore summary provider",
>>>>>> ConstString(“std::fbstring_core<.+>"), stl_summary_flags, true);
>>>>>>
>>>>>> That will work - but what you would see is:
>>>>>>
>>>>>> (const string &const) corpus = error: summary string parsing error: {
>>>>>> (std::*fbstring_core*<char>) store_ = “www"
>>>>>>
>>>>>>
>>>>>> You wanna do
>>>>>>
>>>>>> (lldb) log enable lldb formatters
>>>>>> (lldb) frame variable -T corpus
>>>>>>
>>>>>> It will list one or more typenames - the most specific one is the one
>>>>>> you like (e.g. for libc++ we get std::__1::string - this is how we tell
>>>>>> ourselves this is the std::string from libc++)
>>>>>> Once you find that typename, you’ll make a new formatter -
>>>>>> FBStringSummaryProvider() - and register that formatter with that very
>>>>>> specific typename
>>>>>>
>>>>>> All that FBStringSummaryProvider() has to do is get the “store_”
>>>>>> member (ValueObject::GetChildMemberWithName() is your friend) - and pass it
>>>>>> down to FBStringCoreSummaryProvider()
>>>>>>
>>>>>>
>>>>>> I understand this may seem a little convoluted and arcane at first -
>>>>>> but feel free to ask more questions, and I’ll try to help out!
>>>>>>
>>>>>> Thanks.
>>>>>> Jeffrey
>>>>>>
>>>>>> On Mon, Mar 28, 2016 at 11:38 AM, Enrico Granata <egranata at apple.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This is kind of orthogonal to your problem, but the reason why you
>>>>>>> are not seeing the kind of simplified printing Greg is suggesting, is
>>>>>>> because your std::string doesn’t look like any of the kinds we recognize
>>>>>>>
>>>>>>> Specifically, LLDB data formatters work by matching against type
>>>>>>> names, and once they recognize a typename, then they try to inspect the
>>>>>>> variable in order to grab a summary
>>>>>>> In your example, your std::string exposes a layout that we are not
>>>>>>> handling - hence we bail out of the formatter and we fall back to the raw
>>>>>>> view
>>>>>>>
>>>>>>> If you want pretty printing to work, you’ll need to write a data
>>>>>>> formatter
>>>>>>>
>>>>>>> There are a few avenues. The obvious easy one is to extend the
>>>>>>> existing std::string formatter to recognize your type’s internal layout.
>>>>>>> If one were signing up for more infrastructure work, they could
>>>>>>> decide to try and detect shared library loads and load formatters that
>>>>>>> match with whatever libraries are being loaded.
>>>>>>>
>>>>>>> On Mar 28, 2016, at 9:47 AM, Greg Clayton via lldb-dev <
>>>>>>> lldb-dev at lists.llvm.org> wrote:
>>>>>>>
>>>>>>> So you need to be prepared to escape any text that can have special
>>>>>>> characters. A "std::string" or any container can contain special
>>>>>>> characters. If you are encoding stuff into JSON, you will either need to
>>>>>>> escape any special characters, or hex encode the string into ASCII hex
>>>>>>> bytes.
>>>>>>>
>>>>>>> In debuggers we often get bogus data because variables are not
>>>>>>> initialized, but the compiler tells us that a variable is valid in address
>>>>>>> range [0x1000-0x2000), but it actually is [0x1200-0x2000). If we read a
>>>>>>> variable in this case, a std::string might contain bogus data and the bytes
>>>>>>> might not make sense. So you always have to be prepared for bad data.
>>>>>>>
>>>>>>> If we look at:
>>>>>>>
>>>>>>> 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)
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> We can see the "size_" is zero, and capacity_ is 1441151880758558720
>>>>>>> (which is 0x1400000000000000). "data_" seems to be some random pointer.
>>>>>>>
>>>>>>> On MacOSX, we have a special formatting code that displays
>>>>>>> std::string in CPlusPlusLanguage.cpp that gets installed in the
>>>>>>> LoadLibCxxFormatters() or LoadLibStdcppFormatters() functions with code
>>>>>>> like:
>>>>>>>
>>>>>>> lldb::TypeSummaryImplSP std_string_summary_sp(new
>>>>>>> CXXFunctionSummaryFormat(stl_summary_flags,
>>>>>>> lldb_private::formatters::LibcxxStringSummaryProvider, "std::string summary
>>>>>>> provider"));
>>>>>>> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"),
>>>>>>> std_string_summary_sp);
>>>>>>>
>>>>>>> Special flags are set on std::string to say "don't show children of
>>>>>>> this and just show a summary" So if a std::string contained "hello". So for
>>>>>>> the following code:
>>>>>>>
>>>>>>> std::string h ("hello");
>>>>>>>
>>>>>>> You should just see:
>>>>>>>
>>>>>>> (lldb) fr var h
>>>>>>> (std::__1::string) h = "hello"
>>>>>>>
>>>>>>> If you take a look at the normal value in the raw we see:
>>>>>>>
>>>>>>> (lldb) fr var --raw h
>>>>>>> (std::__1::string) h = {
>>>>>>> __r_ = {
>>>>>>> std::__1::__libcpp_compressed_pair_imp<std::__1::basic_string<char,
>>>>>>> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep,
>>>>>>> std::__1::allocator<char>, 2> = {
>>>>>>> __first_ = {
>>>>>>> = {
>>>>>>> __l = {
>>>>>>> __cap_ = 122511465736202
>>>>>>> __size_ = 0
>>>>>>> __data_ = 0x0000000000000000
>>>>>>> }
>>>>>>> __s = {
>>>>>>> = {
>>>>>>> __size_ = '\n'
>>>>>>> __lx = '\n'
>>>>>>> }
>>>>>>> __data_ = {
>>>>>>> [0] = 'h'
>>>>>>> [1] = 'e'
>>>>>>> [2] = 'l'
>>>>>>> [3] = 'l'
>>>>>>> [4] = 'o'
>>>>>>> [5] = '\0'
>>>>>>> [6] = '\0'
>>>>>>> [7] = '\0'
>>>>>>> [8] = '\0'
>>>>>>> [9] = '\0'
>>>>>>> [10] = '\0'
>>>>>>> [11] = '\0'
>>>>>>> [12] = '\0'
>>>>>>> [13] = '\0'
>>>>>>> [14] = '\0'
>>>>>>> [15] = '\0'
>>>>>>> [16] = '\0'
>>>>>>> [17] = '\0'
>>>>>>> [18] = '\0'
>>>>>>> [19] = '\0'
>>>>>>> [20] = '\0'
>>>>>>> [21] = '\0'
>>>>>>> [22] = '\0'
>>>>>>> }
>>>>>>> }
>>>>>>> __r = {
>>>>>>> __words = {
>>>>>>> [0] = 122511465736202
>>>>>>> [1] = 0
>>>>>>> [2] = 0
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> So the main question is why are our "std::string" formatters not
>>>>>>> kicking in for you. That comes down to a typename match, or the format of
>>>>>>> the string isn't what the formatter is expecting.
>>>>>>>
>>>>>>> But again, since you std::string can contain anything, you will need
>>>>>>> to escape any and all text that is encoded into JSON to ensure it doesn't
>>>>>>> contain anything JSON can't deal with.
>>>>>>>
>>>>>>> On Mar 27, 2016, at 9:20 PM, Jeffrey Tan via lldb-dev <
>>>>>>> lldb-dev at lists.llvm.org> wrote:
>>>>>>>
>>>>>>> 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 = <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}}}}
>>>>>>>
>>>>>>> Utf-16 does not seem to decode it, while 'latin-1' does:
>>>>>>>
>>>>>>> '\xc9'.decode('utf-16')
>>>>>>>
>>>>>>> Traceback (most recent call last):
>>>>>>> File "<stdin>", line 1, in <module>
>>>>>>> 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 <sivachandra at gmail.com>
>>>>>>> wrote:
>>>>>>> On Sat, Mar 26, 2016 at 11:58 PM, Jeffrey Tan <
>>>>>>> jeffrey.fudan at gmail.com> 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 at lists.llvm.org
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> lldb-dev mailing list
>>>>>>> lldb-dev at lists.llvm.org
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> *- Enrico*
>>>>>>> 📩 egranata@.com ☎️ 27683
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> *- Enrico*
>>>>>> 📩 egranata@.com ☎️ 27683
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> *- Enrico*
>>>>> 📩 egranata@.com ☎️ 27683
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> Thanks,
>> *- Enrico*
>> 📩 egranata@.com ☎️ 27683
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160430/325e824a/attachment-0001.html>
More information about the lldb-dev
mailing list