Le débogage Xcode 4.2 ne symbolise pas l'appel de pile

J'ai un problème avec le débogage de Xcode 4.2 dans un simulateur / appareil iOS 5. Le code suivant se bloque, comme prévu:

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

Dans iOS 4, j'obtiens une trace de pile utile de nombres hexadécimaux. Mais dans iOS 5, cela me donne juste:

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

Merci.

Rien de ce que j'ai essayé ne résoudrait cela (j'ai essayé les deux compilateurs, les deux débogueurs, etc.) Après la mise à niveau de XCode pour la mise à jour iOS 5, aucune trace de pile ne semblait fonctionner.

Cependant, j'ai trouvé une solution efficace: créer mon propre gestionnaire d'exceptions (ce qui est également utile pour d'autres raisons). Tout d'abord, créez une fonction qui gérera l'erreur et la sortira sur la console (ainsi que tout ce que vous voulez en faire):

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

Ensuite, ajoutez le gestionnaire d'exceptions à votre délégué d'application:

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

C'est tout!

Si cela ne fonctionne pas, il n'y a que deux raisons possibles :

1. Quelque chose écrase votre NSSetUncaughtExceptionHandlerappel (il ne peut y avoir qu'un seul gestionnaire pour l'ensemble de votre application). Par exemple, certaines bibliothèques tierces définissent leur propre uncaughtExceptionHandler. Alors, essayez de le définir à la FIN de votre didFinishLaunchingWithOptionsfonction (ou de désactiver sélectivement les bibliothèques tierces). Ou mieux encore, définissez un point de rupture symbolique NSSetUncaughtExceptionHandlerpour voir rapidement qui l'appelle. Ce que vous voudrez peut-être faire est de modifier votre version actuelle plutôt que d'en ajouter une autre.
2. Vous ne rencontrez pas réellement d'exception (par exemple, ce EXC_BAD_ACCESSn'est pas une exception; merci aux commentaires de @Erik B, ci-dessous)

Il existe une option utile pour ajouter un point d'arrêt d'exception (en utilisant le + en bas du navigateur de point d'arrêt). Cela cassera sur toute exception (ou vous pouvez définir des conditions). Je ne sais pas si ce choix est nouveau dans la version 4.2 ou si je l'ai finalement remarqué en essayant de contourner le problème des symboles manquants.

Une fois que vous avez atteint ce point d'arrêt, vous pouvez utiliser le navigateur de débogage pour parcourir la pile d'appels, examiner les variables, etc. comme d'habitude.

Si vous voulez une pile d'appels symbolisés adaptée au copier / coller ou autre, gdb backtrace fonctionnera bien à partir de là:

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

(etc)

Il y a une nouvelle fonctionnalité sur le débogueur. Vous pouvez définir un point d'arrêt chaque fois qu'une exception est levée et arrêter l'exécution à cet endroit, comme cela se produisait sur 4.0.

Sur le "Breakpoint Navigator", ajoutez un "Exception Breakpoint" et appuyez simplement sur "Done" dans la fenêtre des options.

C'est tout!

PS: Dans certains cas, il serait préférable de ne rompre que pour les exceptions Objective-C.

Voici une autre solution, pas aussi élégante que la précédente, mais si vous n'avez pas ajouté de points d'arrêt ou de gestionnaires d'exception, cela ne peut être qu'une solution.
Lorsque l'application tombe en panne et que vous obtenez votre première pile d'appels bruts (en nombres hexadécimaux), tapez dans la console Xcode info line *hex(n'oubliez pas les 0xspécificateurs étoile et hexadécimal), par exemple:

(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 vous utilisez lldb , vous pouvez taper image lookup -a hex(sans étoile dans cette situation), et vous obtenez une sortie similaire.

Avec cette méthode, vous pouvez passer du haut de la pile de jet (il y aura environ 5 à 7 propagateurs d'exceptions système) jusqu'à votre fonction qui a causé un plantage, et déterminer le fichier exact et la ligne de code.

De plus, pour un effet similaire, vous pouvez utiliser l'utilitaire atos dans le terminal, tapez simplement:

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

et vous obtenez une trace de pile symbolisée (au moins pour les fonctions, vous avez des symboles de débogage). Cette méthode est plus préférable, car vous n'avez pas pour chaque appel d'adresse info line, copiez simplement les adresses de la sortie de la console et collez-les dans le terminal.

Vous pouvez ajouter un point d' arrêt d'exception (en utilisant le + en bas du navigateur de point d'arrêt) et y ajouter l'action bt (cliquez sur le bouton Ajouter une action, sélectionnez Commande du débogueur, entrez «bt» dans le champ de texte). Cela affichera la trace de la pile dès qu'une exception est levée.

C'est un problème courant, ne pas obtenir de traces de pile dans 4.2. Vous pouvez essayer de permuter entre LLDB et GDB pour voir si vous obtenez de meilleurs résultats.

Déposez un rapport de bogue ici.

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

ÉDITER:

Je crois que si vous revenez à LLVM GCC 4.2, vous ne verrez pas cela se produire. Cependant, vous risquez de perdre les fonctionnalités dont vous avez besoin.

Utilisez ce code dans votre fonction principale:

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;
}

Au type d'invite de la console de débogage de Xcode:

image lookup -a 0x1234

Et cela vous montrera quelque chose comme:

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

Réactiver 'Compile for Thumb' (configuration de débogage) a fonctionné pour moi.