¿Por qué los objetos válidos aparecen como Nil usando lldb? (Apple LLVM Compiler 3.1, Xcode 4.3.1)

Question

Estoy intentando depurar a través de un funky comportamiento UIView y sigo corriendo en el caso donde LLDB es absolutamente inútil y engañoso. Te voy a enseñar lo que quiero decir:

NSLog(@"myView: %@", myView); 

2012-04-20 15:24:57.070 myProj[35789:f803] myView: <MyView: 0x7cc7500; frame = (0 119; 768 885); layer = <CALayer: 0x7cc8030>> 

Pero cuando me puse un punto de interrupción en ese preciso momento y tratar de utilizar el depurador, devuelve nil:

(lldb) po myView 
(MyView *) $552 = 0x00000000 <nil> 

yo intentaría cambiar a GCC 4.2 para ver si ayuda, pero compilar bajo LLVM GCC 4.2 no es una opción ya que este es un proyecto ARC.

Por supuesto, LLDB funcionará si ya sé la dirección correcta para consultar. Pero el vínculo entre los nombres de símbolos y las direcciones parece estar roto para algunos objetos, aunque funciona para la mayoría de los otros objetos.

(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>> 

¿Cómo puedo reparar esto? Incluso he probado self-> myView, que tampoco funcionó.

Actualización: (Se pone peor!)

Debo añadir que myView es una variable de clase, no una propiedad, en este ejemplo (donde LLDB lo asocia con nula). Si hago myView una propiedad de clase y @synthesize it, lldb obtendrá un valor incorrecto pero predecible y asociará el símbolo myView con la propiedad sintetizada más reciente ANTES de @synthesize. Así que en mi caso el código se veía así:

@synthesize myDate=myDate_; 
@synthesize myView; 

Así que cuando la evaluación de la propiedad para myView de LLDB, que muestra la fecha almacenada en myDate_:

(lldb) po myView 
(MyView *) $24 = 0x07ca0900 2008-01-08 05:00:00 +0000 

En este último caso, si hago MyView una variable método, LLDB será correcta:

(lldb) po myView 
(UIView *) $7 = 0x07d81080 <MyView: 0x7d81080; frame = (0 119; 768 885); layer = <CALayer: 0x7d81b70>> 

Esto huele a un error muy evidente en sí mismo LLDB.

Actualización 2:

investigación adicional: Parece que todas las propiedades de clase están equivocados! La primera propiedad en la lista muestra un valor de nil en LLDB, y todos los demás muestran el valor de la sintetizada justo antes.

¿Podría ser este un extraño error de configuración?

Answer 1

La solución parece ser: evitar las pruebas en el simulador cuando se intenta utilizar el depurador. Una vez que empecé a probar en el dispositivo, toda la locura desapareció y comenzó a funcionar como se esperaba. Si volví al simulador, volví a ver los mismos errores. Las propiedades y las variables de método parecían tener problemas en el simulador.

Answer 2

frame variable -o myView 

More here bajo 'EXAMEN PILA MARCO DEL ESTADO' título.

Answer 3

Asegúrese de que la configuración de compilación esté configurada como Debug y no AdHoc, Release o cualquier otra cosa que elimine los símbolos de depuración o no permita la depuración en el archivo de derechos.

Esto simplemente me mordió porque olvidé cambiar la configuración a Debug después de crear una compilación ad hoc para mi dispositivo. Curiosamente, la mayor parte de la aplicación funcionaba, pero ciertos marcos de pila fallaban silenciosa e inexplicablemente, con todas las variables (incluyendo self) nulas o destrozadas.