I’m trying to debug through some funky UIView behavior and I keep running into the case where LLDB is absolutely useless and misleading. Let me show you what I mean:
NSLog(@"myView: %@", myView);
2012-04-20 15:24:57.070 myProj[35789:f803] myView: <MyView: 0x7cc7500; frame = (0 119; 768 885); layer = <CALayer: 0x7cc8030>>
But when I set a breakpoint at that exact moment and try to use the debugger, it returns nil:
(lldb) po myView
(MyView *) $552 = 0x00000000 <nil>
I would try shifting to GCC 4.2 to see if it helps, but compiling under LLVM GCC 4.2 is not an option as this is an ARC project.
Of course, LLDB will work if I already know the correct address to query. But the link between symbol names and the addresses seems to be broken for some objects, though it works for most other objects.
(lldb) po self
(MyViewController *const) $51 = 0x07e92200 <MyViewController: 0x7e92200>
(lldb) po myView
(MyView *) $25 = 0x00000000 <nil>
2012-04-20 15:44:17.250 myProject[37551:f803] myView: <MyView: 0x7e8e240; frame = (0 119; 768 885); layer = <CALayer: 0x7ea2330>>
(lldb) po 0x7e8e240
(int) $50 = 132702784 <MyView: 0x7e8e240; frame = (0 119; 768 885); layer = <CALayer: 0x7ea2330>>
How can I fix this? I’ve even tried self->myView, which didn’t work either.
Update: (It gets worse!)
I should add that myView is a class variable, not a property, in this example (where lldb associates it with nil).
If I make myView a class property and @synthesize it, lldb will obtain an incorrect but predictable value and it will associate the myView symbol with the most recently synthesized property BEFORE the @synthesize. So in my case the code looked like this:
@synthesize myDate=myDate_;
@synthesize myView;
So when evaluating the property for myView from LLDB, it shows the date stored in myDate_:
(lldb) po myView
(MyView *) $24 = 0x07ca0900 2008-01-08 05:00:00 +0000
In the last case, if I make myView a method variable, LLDB will be correct:
(lldb) po myView
(UIView *) $7 = 0x07d81080 <MyView: 0x7d81080; frame = (0 119; 768 885); layer = <CALayer: 0x7d81b70>>
This smells like a very obvious bug in LLDB itself.
Update 2:
Further research: It looks like ALL of the class properties are wrong! The first property in the list shows a value of nil in LLDB, and all others show the value of the one synthesized right before it.
Could this be a weird config error?
The solution seems to be: avoid testing in the simulator when trying to use the debugger. Once I started testing on the device, all craziness went away and it started worked as expected. If I went back to the simulator I saw the same bugs again. Properties and method variables seemed to both have issues in the simulator.