[lldb-dev] lldb showing wrong type structure for virtual pointer type

[jonas echterhoff via lldb-dev]

> On Feb 28, 2018, at 9:27 PM, Jim Ingham <jingham at apple.com> wrote:
> 
> Interesting.  
> 
> First off, you can turn off fetching dynamic values globally (including in the Xcode Locals view) by putting:
> 
> settings set target.prefer-dynamic-value no-dynamic-values

> in your ~/.lldbinit file.  You can toggle this on and off in a session, though Xcode won't notice you've changed the value till you cause it to refresh the locals (step or whatever).

This will fix the output of "frame variable". But it does not seem to fix the variable display in the UI.

> We do log the process of finding the dynamic type.  You can see this by running the command:
> 
> log enable -f /tmp/lldb-object-log.txt lldb object
> 
> Probably easiest to put that in your .lldbinit.
> 
> That channel also logs when we read in modules, and so it might be a little chatty, but you should see:
> 
> <SOME_ADDRESS>: static-type = '<STATIC_TYPE>' has vtable symbol 'vtable for <DYNAMIC_CLASS>'
> 
> and then some more messages that trace our attempt to look up DYNAMIC CLASS.  If you turn on those logs, what do you see for these classes?

0x000000010f62ecd0: static-type = 'Transform *' has vtable symbol 'vtable for Transform'

0x000000010f62ecd0: static-type = 'Transform *' has dynamic type: uid={0x100012d7a}, type-name='Transform'

jonas

> 
> Jim
> 
> 
>> On Feb 28, 2018, at 12:03 PM, jonas echterhoff <jonas at unity3d.com> wrote:
>> 
>> 
>> 
>>> On Feb 28, 2018, at 7:14 PM, Jim Ingham <jingham at apple.com> wrote:
>>> 
>>> Jonas,
>>> 
>>> What are you using to inspect the this pointer?
>> 
>> Normally, the Xcode debugger UI.
>> 
>>> You can use "frame variable" (the equivalent of gdb's "info locals") which just relies on debug info or the expression evaluator e.g. "print".  Do both methods show the same problem?
>> 
>> (lldb) frame variable this
>> (Scripting::UnityEngine::Transform *) this = 0x000000010fe2eb20
>> 
>> That gives me the wrong namespace
>> 
>> (lldb) print this
>> (Scripting::UnityEngine::Transform *) $4 = 0x000000010fe2eb20
>> 
>> That also gives me the wrong namespace
>> 
>> But:
>> 
>> (lldb) print *this
>> (Transform) $5 = {
>> [...]
>> 
>> gives me the correct (global) namespace.
>> 
>> Also:
>> 
>> (lldb) frame variable -d no-dynamic-values this
>> (Transform *) this = 0x000000010fe2eb20
>> 
>> gives me the correct namespace.
>> 
>>> 
>>> Also note that lldb by default will try to discern the full dynamic type of the variables it prints.  You can disable this by doing:
>>> 
>>> (lldb) expr -d no-dynamic-values -- this
>>> 
>>> or equivalently:
>>> 
>>> (lldb) frame variable -d no-dynamic-values this
>>> 
>>> Is it the dynamic value resolution that's causing the incorrect printing?
>> 
>> Yes, both of those above give me the correct types!
>> 
>> Now, this is already very helpful - Thank you! 
>> This means I can get correct values using the lldb console. If there was some way to make the Xcode UI show the correct values, that would be even better.
>> 
>> jonas
>> 
>>> 
>>> Jim
>>> 
>>> 
>>> 
>>> 
>>>> On Feb 28, 2018, at 3:03 AM, jonas echterhoff via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>>> 
>>>> 
>>>>> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov <dantipov at nvidia.com> wrote:
>>>>> 
>>>>> On 02/28/2018 11:31 AM, jonas echterhoff via lldb-dev wrote:
>>>>> 
>>>>>> I'm using lldb-900.0.64.
>>>>>        ^^^^^^^^^^^^^^
>>>>>        ??????????????
>>>>> Latest official release is 5.0.1; also there are 6.0.0 (at -rc3, the next release)
>>>>> and 7.0.0 (a.k.a SVN trunk). What's the 'version' output of your LLDB prompt?
>>>> 
>>>> It is what I posted:
>>>> 
>>>> jechter$ lldb --version
>>>> lldb-900.0.64
>>>> Swift-4.0
>>>> 
>>>> Maybe Apple uses a different versioning scheme for lldb distributed with their toolchains?
>>>>> 
>>>>>> Unfortunately, I have not yet succeeded in coming up with a small, independent repro case which shows this problem.
>>>>> 
>>>>> IIUC this is it:
>>>> 
>>>> [...]
>>>> 
>>>>> Here 'this' is different between calls to obj2.f () and obj2.g () (0x00007fffffffdb50 vs.
>>>>> 0x00007fffffffdb40), and objects are shown as different as well - {111, 222} vs. {333, 444}.
>>>> 
>>>> Thanks. What you are showing there seems very peculiar. 
>>>> 
>>>> But I don't think it's the same problem as I have (and also, using the same steps on my machine does not repro the problem you showed - I get the same value for "this" and it's members between the calls to S::B::f and S::B::g).
>>>> 
>>>> My problem was not about showing a wrong object (My "this" pointer value was correct), but about showing a wrong type representation of the correct object data.
>>>> 
>>>> jonas
>>>> 
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> lldb-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> 
>> 
>