<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 13, 2016, at 10:11 AM, Jeffrey Tan <<a href="mailto:jeffrey.fudan@gmail.com" class="">jeffrey.fudan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">One quick question: do we support getting type summary string from inferior method call?</div></div></blockquote><div><br class=""></div><div>No - for that you are going to need to write a Python formatter.</div><div><br class=""></div><div>Running code in formatters is a risky endeavor for a bunch of reasons, so it is by design that it is not an easily accessible building block</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""> 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.</div></div></blockquote><div><br class=""></div><div>Because, as you say, it has a high risk of side effects</div><div>Also, it is less efficient than direct memory reads (I have a comparison graph somewhere where some data formatter became an order of magnitude faster once it stopped running code)</div><div>Also, what happens when your object is in scope but not yet initialized, or you’re stopped in its destructor and it’s partially torn down? Are you going to make all your methods able to deal safely with states that should never happen in production because you might actually run into them in the debugger?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""> 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). <div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>The model you’re describing is similar to the “po” model we have in ObjC and Swift. Those languages provide a sanctioned language-blessed way to create an object description in program code (see -description for ObjC, and the whole Mirror story for Swift)</div><div>Those are OK because they are only triggered by explicit user action (running the “po” command in the debugger), and yet we still occasionally see problems with them where the user didn’t realize the program state was corrupt enough that running code there was a bad idea</div><div><br class=""></div><div>C++ has no such sanctioned mechanism to generate descriptions - if one came about, LLDB would support it, in the form of making “po” do the right thing for C++ objects</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Jeffrey</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Apr 7, 2016 at 10:33 AM, Enrico Granata <span dir="ltr" class=""><<a href="mailto:egranata@apple.com" target="_blank" class="">egranata@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Apr 6, 2016, at 7:31 PM, Jeffrey Tan <<a href="mailto:jeffrey.fudan@gmail.com" target="_blank" class="">jeffrey.fudan@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Thanks Enrico. This is very detailed! I will take a look. <div class="">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: <a href="https://msdn.microsoft.com/en-us/library/jj620914.aspx" target="_blank" class="">https://msdn.microsoft.com/en-us/library/jj620914.aspx</a></div><div class="">This will make adding data formatter more extensible/flexible. Any reason we did not take this approach? </div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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</div><div class="">This has the bonus of being really easy, since you’re writing code in the same language/context of the types you’re formatting</div><div class="">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)</div><div class="">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</div><div class="">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.</div><div class="">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++</div><div class="">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</div><div class=""><div class="h5"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Jeffrey</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Apr 6, 2016 at 11:49 AM, Enrico Granata <span dir="ltr" class=""><<a href="mailto:egranata@apple.com" target="_blank" class="">egranata@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Apr 5, 2016, at 2:42 PM, Jeffrey Tan <<a href="mailto:jeffrey.fudan@gmail.com" target="_blank" class="">jeffrey.fudan@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hi Enrico,<div class=""><br class=""></div><div class="">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 "<b class="">fbstring_core</b>" which I assume I need to write a type summary for this type:</div><div class=""><br class=""></div><div class=""><div class="">frame variable corpus -T</div><div class="">(const string &const) corpus = error: summary string parsing error: {</div><div class=""> (std::<b class="">fbstring_core</b><char>) store_ = {</div><div class=""> (std::<b class="">fbstring_core</b><char>::(anonymous union)) = {</div><div class=""> (char [24]) small_ = "www"</div><div class=""> (std::fbstring_core<char>::MediumLarge) ml_ = {</div><div class=""> (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��</div><div class=""> (std::size_t) size_ = 0</div><div class=""> (std::size_t) capacity_ = 1441151880758558720</div><div class=""> }</div><div class=""> }</div><div class=""> }</div><div class="">}</div></div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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</div><div class=""><br class=""></div><div class="">There’s going to be two parts to getting this to work:</div><div class=""><br class=""></div><div class=""><b class="">Part 1 - Formatting fbstring_core</b></div><div class=""><br class=""></div><div class="">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)</div><div class="">I assume that the way you tell one from the other is</div><div class=""><br class=""></div><div class="">if (size == 0) small</div><div class="">else medium-large</div><div class=""><br class=""></div><div class="">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 :-)</div><div class=""><br class=""></div><div class="">Armed with that knowledge, look in lldb source/Plugins/Language/CPlusPlus/Formatters/LibCxx.cpp</div><div class="">There’s a bunch of code that deals with formatting llvm’s libc++ std::string - which follows a very similar logic to your class</div><div class=""><br class=""></div><div class=""><div style="margin:0px;font-size:13px;line-height:normal;font-family:'CMU Typewriter Text'" class=""><span class="">ExtractLibcxxStringInfo() </span>is the function that handles discovering which layout the string uses - where the data lives - and how much data there is</div></div><div class=""><br class=""></div><div class="">Once you have told yourself how much data there is (the size) and where it lives (array or pointer), <span style="font-family:'CMU Typewriter Text';font-size:13px" class="">LibcxxStringSummaryProvider() </span>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</div><div class="">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</div><div class=""><br class=""></div><div class=""><b class="">Part 2 - Teaching std::string that it can be backed by an fbstring_core</b></div><div class=""><br class=""></div><div class="">At the end of part 1, you’ll probably end up with a FBStringCoreSummaryProvider() - now you need to teach LLDB about it</div><div class="">The obvious thing you could do would be to go in <span style="color:rgb(79,129,135);font-family:'CMU Typewriter Text';font-size:13px" class="">CPlusPlusLanguage</span><span style="font-family:'CMU Typewriter Text';font-size:13px" class="">::GetFormatters() </span>add a LoadFBStringFormatter(g_category) to it - and then imitate - say - <span style="font-family:'CMU Typewriter Text';font-size:13px" class="">LoadLibCxxFormatters()</span></div><div class=""><br class=""></div><div class=""><div style="margin:0px;font-size:13px;line-height:normal;font-family:'CMU Typewriter Text';color:rgb(209,47,27)" class=""><span class=""> </span><span style="color:#31595d" class="">AddCXXSummary</span><span class="">(cpp_category_sp, </span><span style="color:#4f8187" class="">lldb_private</span><span class="">::</span><span style="color:#4f8187" class="">formatters</span><span class="">::</span><span style="color:#31595d" class="">FBStringCoreSummaryProvider</span><span class="">, </span><span class="">“fbstringcore summary provider"</span><span class="">, </span><span style="color:#4f8187" class="">ConstString</span><span class="">(</span><span class="">“std::fbstring_core<.+>"</span><span class="">), stl_summary_flags, </span><span style="color:#bb2ca2" class="">true</span><span class="">);</span></div><div class=""><span class=""><br class=""></span></div><div class=""><span class="">That will work - but what you would see is:</span></div><div class=""><span class=""><br class=""></span></div><div class=""><span class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><span class=""><div class="">(const string &const) corpus = error: summary string parsing error: {</div></span><div class=""> (std::<b class="">fbstring_core</b><char>) store_ = “www"</div></div></div></blockquote><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">You wanna do</div><div class=""><br class=""></div><div class="">(lldb) log enable lldb formatters</div><div class="">(lldb) frame variable -T corpus</div><div class=""><br class=""></div><div class="">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++)</div><div class="">Once you find that typename, you’ll make a new formatter - FBStringSummaryProvider() - and register that formatter with that very specific typename</div><div class=""><br class=""></div><div class="">All that FBStringSummaryProvider() has to do is get the “store_” member (ValueObject::GetChildMemberWithName() is your friend) - and pass it down to FBStringCoreSummaryProvider()</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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!</div></div></div></div></span></div></div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Thanks.</div><div class="">Jeffrey<br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Mar 28, 2016 at 11:38 AM, Enrico Granata <span dir="ltr" class=""><<a href="mailto:egranata@apple.com" target="_blank" class="">egranata@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">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</div><div class=""><br class=""></div><div class="">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</div><div class="">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</div><div class=""><br class=""></div><div class="">If you want pretty printing to work, you’ll need to write a data formatter</div><div class=""><br class=""></div><div class="">There are a few avenues. The obvious easy one is to extend the existing std::string formatter to recognize your type’s internal layout.</div><div class="">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.</div><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 28, 2016, at 9:47 AM, Greg Clayton via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div class="">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. <br class=""><br class="">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.<br class=""><br class="">If we look at:<br class=""><br class=""> store_ = {<br class=""> = {<br class=""> small_ = "www"<br class=""> ml_ = (data_ =<br class="">"��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",<br class="">size_ = 0, capacity_ = 1441151880758558720)<br class=""> }<br class=""> }<br class="">}<br class=""><br class="">We can see the "size_" is zero, and capacity_ is 1441151880758558720 (which is 0x1400000000000000). "data_" seems to be some random pointer. <br class=""><br class="">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:<br class=""><br class=""> lldb::TypeSummaryImplSP std_string_summary_sp(new CXXFunctionSummaryFormat(stl_summary_flags, lldb_private::formatters::LibcxxStringSummaryProvider, "std::string summary provider"));<br class=""> cpp_category_sp->GetTypeSummariesContainer()->Add(ConstString("std::__1::string"), std_string_summary_sp);<br class=""><br class="">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:<br class=""><br class="">std::string h ("hello");<br class=""><br class="">You should just see:<br class=""><br class="">(lldb) fr var h<br class="">(std::__1::string) h = "hello"<br class=""><br class="">If you take a look at the normal value in the raw we see:<br class=""><br class="">(lldb) fr var --raw h<br class="">(std::__1::string) h = {<br class=""> __r_ = {<br class=""> 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> = {<br class=""> __first_ = {<br class=""> = {<br class=""> __l = {<br class=""> __cap_ = 122511465736202<br class=""> __size_ = 0<br class=""> __data_ = 0x0000000000000000<br class=""> }<br class=""> __s = {<br class=""> = {<br class=""> __size_ = '\n'<br class=""> __lx = '\n'<br class=""> }<br class=""> __data_ = {<br class=""> [0] = 'h'<br class=""> [1] = 'e'<br class=""> [2] = 'l'<br class=""> [3] = 'l'<br class=""> [4] = 'o'<br class=""> [5] = '\0'<br class=""> [6] = '\0'<br class=""> [7] = '\0'<br class=""> [8] = '\0'<br class=""> [9] = '\0'<br class=""> [10] = '\0'<br class=""> [11] = '\0'<br class=""> [12] = '\0'<br class=""> [13] = '\0'<br class=""> [14] = '\0'<br class=""> [15] = '\0'<br class=""> [16] = '\0'<br class=""> [17] = '\0'<br class=""> [18] = '\0'<br class=""> [19] = '\0'<br class=""> [20] = '\0'<br class=""> [21] = '\0'<br class=""> [22] = '\0'<br class=""> }<br class=""> }<br class=""> __r = {<br class=""> __words = {<br class=""> [0] = 122511465736202<br class=""> [1] = 0<br class=""> [2] = 0<br class=""> }<br class=""> }<br class=""> }<br class=""> }<br class=""> }<br class=""> }<br class="">}<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class=""><blockquote type="cite" class="">On Mar 27, 2016, at 9:20 PM, Jeffrey Tan via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="">lldb-dev@lists.llvm.org</a>> wrote:<br class=""><br class="">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. <br class=""><br class="">Here is the correct decoding from gdb whic might be useful:<br class="">(gdb) p corpus<br class="">$3 = (const std::string &) @0x7fd133cfb888: {<br class=""> static npos = 18446744073709551615, store_ = {<br class=""> static kIsLittleEndian = <optimized out>,<br class=""> static kIsBigEndian = <optimized out>, {<br class=""> small_ = "www", '\000' <repeats 20 times>, "\024", ml_ = {<br class=""> 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,<br class=""> capacity_ = 1441151880758558720}}}}<br class=""><br class="">Utf-16 does not seem to decode it, while 'latin-1' does:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">'\xc9'.decode('utf-16')<br class=""></blockquote></blockquote></blockquote>Traceback (most recent call last):<br class=""> File "<stdin>", line 1, in <module><br class=""> File "/mnt/gvfs/third-party2/python/55c1fd79d91c77c95932db31a4769919611c12bb/2.7.8/centos6-native/da39a3e/lib/python2.7/encodings/utf_16.py", line 16, in decode<br class=""> return codecs.utf_16_decode(input, errors, True)<br class="">UnicodeDecodeError: 'utf16' codec can't decode byte 0xc9 in position 0: truncated data<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">'\xc9'.decode('latin-1')<br class=""></blockquote></blockquote></blockquote>u'\xc9'<br class=""><br class="">Instead of guessing what kind of decoding I should use, I would use 'ensure_ascii=False' to prevent the crash for now.<br class=""><br class="">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. <br class=""><br class="">Thanks<br class="">Jeffrey<br class=""><br class="">On Sun, Mar 27, 2016 at 2:49 PM, Siva Chandra <<a href="mailto:sivachandra@gmail.com" target="_blank" class="">sivachandra@gmail.com</a>> wrote:<br class="">On Sat, Mar 26, 2016 at 11:58 PM, Jeffrey Tan <<a href="mailto:jeffrey.fudan@gmail.com" target="_blank" class="">jeffrey.fudan@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class="">Btw: after patching with Siva's fix <a href="http://reviews.llvm.org/D18008" target="_blank" class="">http://reviews.llvm.org/D18008</a>, the<br class="">first field 'small_' is fixed, however the second field 'ml_' still emits<br class="">garbage:<br class=""><br class="">(lldb) fr v corpus<br class="">(const string &const) corpus = error: summary string parsing error: {<br class=""> store_ = {<br class=""> = {<br class=""> small_ = "www"<br class=""> ml_ = (data_ =<br class="">"��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",<br class="">size_ = 0, capacity_ = 1441151880758558720)<br class=""> }<br class=""> }<br class="">}<br class=""></blockquote><br class="">Do you still see the DW_TAG_member related error?<br class=""><br class="">A wild (and really wild at that) guess: Is it utf16 data that is being<br class="">decoded as utf8?<br class=""><br class="">As David Blaikie mentioned on the other thread, it would really help<br class="">if you provide us with a minimal example to repro this. Atleast, repro<br class="">instructions.<br class=""><br class="">_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="">lldb-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class=""></blockquote><br class="">_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="">lldb-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class=""></div></div></blockquote></div><br class=""></div></div><div class="">
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class="">Thanks,</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><i class="">- Enrico</i><br class="">📩 egranata@<font color="#ff2600" class=""></font>.com ☎️ 27683</div>
</div>
<br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div></div></div><div class=""><div class=""><br class=""><div class="">
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class="">Thanks,</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><i class="">- Enrico</i><br class="">📩 egranata@<font color="#ff2600" class=""></font>.com ☎️ 27683</div>
</div>
<br class=""></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div></div></div><div class=""><div class="h5"><br class=""><div class="">
<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><br class="">Thanks,</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><i class="">- Enrico</i><br class="">📩 egranata@<font color="#ff2600" class=""></font>.com ☎️ 27683</div>
</div>
<br class=""></div></div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""><div class="">
<div class="" style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline">Thanks,</div><div class="" style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><i class="">- Enrico</i><br class="">📩 egranata@<font color="#ff2600" class=""></font>.com ☎️ 27683</div>
</div>
<br class=""></div></body></html>