[lldb-dev] lldb showing wrong type structure for virtual pointer type
Hi,
I'm having a problem where lldb will resolve the wrong type for virtual
pointers, showing incorrect data for variables. This makes debugging our
project very hard.
In our project, we commonly have the following structure:
class Transform : SomeParentClass
{
virtual foo();
void bar();
/*...*/
}
namespace Scripting {
class Transform : SomeScriptingParentClass
{
/*...*/
}
}
ie, we have native internal classes (like "Transform" in this case), and
wrapper classes with identical names (but in a different namespace). (These are
used to link the native class to a user facing API of the same name).
Now, when I put a breakpoint into "Transform::bar" and try to inspect the
"this" variable, lldb shows "this" as a pointer to "Scripting::Transform"
instead of as a pointer to "::Transform", thus showing the wrong data and
making it impossible to inspect it's member variables. Since this is a common
structure in our code, it makes debugging very hard.
Now, it seems that this is caused by Transform being a virtual class. So lldb
will try to derive it's type at runtime by looking at the symbol name of the
vtable (which is "__ZTV9Transform"). Then it will incorrectly map that to
"Scripting::Transform" instead of "::Transform", which seems to be a bug in
lldb.
I can work around the problem by patching the mach-o binary to remove the name
of the vtable ("__ZTV9Transform") from the symbol table. Then lldb will be
unable to look up the type dynamically at runtime, and use the dwarf info of
the "bar" function, which specifies "this" to be a pointer to "::Transform".
Obviously, this is a rather inconvenient workaround.
I guess I could rename the scripting representations of all our classes to use
a different naming scheme (like "Scripting::_Transform"), but I'd only like to
do that as a last resort.
I'm using lldb-900.0.64.
Unfortunately, I have not yet succeeded in coming up with a small, independent
repro case which shows this problem.
So I'm wondering:
-Is this a known issue?
-Is there a fix?
-Any ideas for a better workaround?
Thanks for any help!
jonas
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type
> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov 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 ()
> (0x7fffdb50 vs.
> 0x7fffdb40), 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@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type
> On Feb 28, 2018, at 7:14 PM, Jim Ingham 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 = 0x00010fe2eb20
That gives me the wrong namespace
(lldb) print this
(Scripting::UnityEngine::Transform *) $4 = 0x00010fe2eb20
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 = 0x00010fe2eb20
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
>> wrote:
>>
>>
>>> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov 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 ()
>>> (0x7fffdb50 vs.
>>> 0x7fffdb40), 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@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type
> On Feb 28, 2018, at 9:27 PM, Jim Ingham 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:
>
> : static-type = '' has vtable symbol 'vtable for
> '
>
> 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?
0x00010f62ecd0: static-type = 'Transform *' has vtable symbol 'vtable for
Transform'
0x00010f62ecd0: static-type = 'Transform *' has dynamic type:
uid={0x100012d7a}, type-name='Transform'
jonas
>
> Jim
>
>
>> On Feb 28, 2018, at 12:03 PM, jonas echterhoff wrote:
>>
>>
>>
>>> On Feb 28, 2018, at 7:14 PM, Jim Ingham 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 = 0x00010fe2eb20
>>
>> That gives me the wrong namespace
>>
>> (lldb) print this
>> (Scripting::UnityEngine::Transform *) $4 = 0x00010fe2eb20
>>
>> 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 = 0x00010fe2eb20
>>
>> 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
>>>> wrote:
>>>>
>>>>
>>>>> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov 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 ()
>>>>> (0x7fffdb50 vs.
>>>>> 0x7fffdb40), 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@lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb showing wrong type structure for virtual pointer type
t;>>>
>>>> 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 = 0x00010fe2eb20
>>>>
>>>> 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
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> On Feb 28, 2018, at 11:19 AM, Dmitry Antipov
>>>>>>> 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 ()
>>>>>>> (0x7fffdb50 vs.
>>>>>>> 0x7fffdb40), 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@lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
