La depuración de Xcode 4.2 no simboliza la llamada de la pila

Tengo un problema con la depuración de Xcode 4.2 en un simulador / dispositivo iOS 5. El siguiente código se bloquea, como se esperaba:

NSArray *arr=[NSArray array];
[arr objectAtIndex:100];

En iOS 4, obtengo un útil seguimiento de la pila de números hexadecimales. Pero en iOS 5, solo me da:

*** First throw call stack:
(0x16b4052 0x1845d0a 0x16a0674 0x294c 0x6f89d6 0x6f98a6 0x708743 0x7091f8 0x7fcaa9 0x2257fa9 0x16881c5 0x15ed022 0x15eb90a 0x15eadb4 0x15eaccb 0x6f02a7 0x6faa93 0x2889 0x2805)

Gracias.

Nada de lo que probé solucionaría esto (probé ambos compiladores, ambos depuradores, etc.) Después de actualizar XCode para la actualización de iOS 5, no parecía funcionar ningún seguimiento de la pila.

Sin embargo, he encontrado una solución eficaz: crear mi propio controlador de excepciones (que también es útil por otros motivos). Primero, cree una función que maneje el error y lo envíe a la consola (así como cualquier otra cosa que desee hacer con él):

void uncaughtExceptionHandler(NSException *exception) {
    NSLog(@"CRASH: %@", exception);
    NSLog(@"Stack Trace: %@", [exception callStackSymbols]);
    // Internal error reporting
}

A continuación, agregue el controlador de excepciones a su delegado de aplicaciones:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{   
    NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler);
    // Normal launch stuff
}

¡Eso es!

Si esto no funciona, solo hay dos posibles razones :

1. Algo está sobrescribiendo su NSSetUncaughtExceptionHandlerllamada (solo puede haber un controlador para toda su aplicación). Por ejemplo, algunas bibliotecas de terceros establecen su propio UncaughtExceptionHandler. Por lo tanto, intente configurarlo al final de su didFinishLaunchingWithOptionsfunción (o deshabilite selectivamente las bibliotecas de terceros). O mejor aún, establezca un punto de interrupción simbólico NSSetUncaughtExceptionHandlerpara ver rápidamente quién lo está llamando. Lo que puede hacer es modificar su actual en lugar de agregar otro.
2. En realidad no estás encontrando una excepción (por ejemplo, noEXC_BAD_ACCESS es una excepción; crédito a los comentarios de @Erik B, a continuación)

Hay una opción útil para agregar un punto de interrupción de excepción (usando el + en la parte inferior del navegador de punto de interrupción). Esto se romperá en cualquier Excepción (o puede establecer condiciones). No sé si esta opción es nueva en 4.2 o si finalmente me di cuenta de que estaba tratando de solucionar el problema de los símbolos faltantes.

Una vez que llegue a este punto de interrupción, puede usar el navegador de depuración para navegar por la pila de llamadas, examinar variables, etc., como de costumbre.

Si desea una pila de llamadas simbolizadas adecuada para copiar / pegar o similares, la traza inversa de gdb funcionará bien desde allí:

(gdb) bt
#0  0x01f84cf0 in objc_exception_throw ()
#1  0x019efced in -[NSObject doesNotRecognizeSelector:] ()

(etc.)

Hay una nueva característica en el depurador. Puede establecer un punto de interrupción cada vez que se produce una excepción y detener la ejecución allí, tal como solía ocurrir en 4.0.

En el "Navegador de punto de interrupción", agregue un "Punto de interrupción de excepción" y simplemente presione "Listo" en la ventana emergente de opciones.

¡Eso es todo!

PD: En algunos casos sería mejor romper solo para excepciones de Objective-C.

Aquí hay una solución más, no tan elegante como la anterior, pero si no agregó puntos de interrupción o controladores de excepción, puede ser solo un camino a seguir.
Cuando la aplicación se bloquea y obtiene su pila de llamadas de primer lanzamiento sin procesar (en números hexadecimales), escriba en la consola Xcode info line *hex(no olvide el 0xespecificador de estrella y hexadecimal), por ejemplo:

(gdb) info line *0x2658
Line 15 of "path/to/file/main.m" starts at address 0x25f2 <main+50>
and ends at 0x267e <main+190>.

Si está utilizando lldb , puede escribirimage lookup -a hex (sin en esta situación) y obtendrá un resultado similar.

Con este método, puede atravesar desde la parte superior de la pila de lanzamiento (habrá aproximadamente 5-7 propagadores de excepción del sistema) a su función que causó un bloqueo, y determinar el archivo y la línea de código exactos.

Además, para un efecto similar, puede usar la utilidad atos en la terminal, simplemente escriba:

atos -o path/to/AplicationBundle.app/Executable 0xAdress1 0xAdress2 0xAdress3 ...

y obtiene un seguimiento de pila simbolizado (al menos para las funciones que tiene símbolos de depuración). Este método es más preferible, ya que no tiene para cada llamada de dirección info line, simplemente copie las direcciones de la salida de la consola y péguelas en la terminal.

Puede agregar un punto de interrupción de excepción (usando el + en la parte inferior del navegador del punto de interrupción) y agregarle la acción bt (haga clic en el botón Agregar acción, seleccione Comando del depurador, ingrese "bt" en el campo de texto). Esto mostrará el seguimiento de la pila tan pronto como se produzca una excepción.

Este es un problema común, no obtener rastros de pila en 4.2. Puede intentar cambiar entre LLDB y GDB para ver si obtiene mejores resultados.

Presente un informe de error aquí.

http://developer.apple.com/bugreporter/

EDITAR:

Creo que si vuelve a cambiar a LLVM GCC 4.2, no verá que esto suceda. Sin embargo, puede perder las características que necesita.

Use este código en su función principal:

int main(int argc, char *argv[])
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    int retVal;
    @try {
        retVal = UIApplicationMain(argc, argv, nil, nil);
    }
    @catch (NSException *exception) {
        NSLog(@"CRASH: %@", exception);
        NSLog(@"Stack Trace: %@", [exception callStackSymbols]);
    }
    @finally {
        [pool release];
    }
    return retVal;
}

En el indicador de consola de depuración de Xcode, escriba:

image lookup -a 0x1234

Y te mostrará algo como:

  Address: MyApp[0x00018eb0] (MyApp.__TEXT.__text + 91088)
  Summary: MyApp`-[MyViewController viewDidAppear:] + 192 at MyViewController.m:202

Activar 'Compilar para Thumb' nuevamente (configuración de depuración) funcionó para mí.