iOS
Débogage des pannes

Recherche d'informations sur un crash

Lorsque votre application plante, Xcode entre dans le débogueur et affiche plus d'informations sur le crash:

Les parties les plus importantes sont:

La flèche rouge

La flèche rouge indique quelle ligne de code a planté et pourquoi elle est tombée en panne.

La console du débogueur

De nombreux incidents enregistrent plus d'informations sur la console du débogueur. Il devrait apparaître automatiquement lorsque l'application plante, mais si ce n'est pas le cas, affichez le débogueur en sélectionnant bouton dans le coin supérieur droit de Xcode, et affichez la console en cliquant sur le bouton bouton dans le coin inférieur droit du débogueur.

La trace de la pile

La trace de la pile répertorie les fonctions du programme avant qu'il n'atteigne le code qui a planté.

Une partie de la trace de la pile est affichée dans le navigateur de débogage à gauche de l'écran et les commandes du débogueur permettent de sélectionner un cadre de pile à afficher dans le débogueur:

Si vous entrez dans la bt commande à la (lldb) invite dans le débogueur et appuyez sur le retour, vous obtiendrez une représentation textuelle de la trace de la pile que vous pouvez copier et coller:

(lldb) bt
* thread #1: tid = 0x3aaec5, 0x00007fff91055f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff91055f06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x000000010008142d libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff96dc76e7 libsystem_c.dylib`abort + 129
    frame #3: 0x00007fff8973bf81 libc++abi.dylib`abort_message + 257
    frame #4: 0x00007fff89761a47 libc++abi.dylib`default_terminate_handler() + 267
    frame #5: 0x00007fff94f636ae libobjc.A.dylib`_objc_terminate() + 103
    frame #6: 0x00007fff8975f19e libc++abi.dylib`std::__terminate(void (*)()) + 8
    frame #7: 0x00007fff8975ec12 libc++abi.dylib`__cxa_throw + 121
    frame #8: 0x00007fff94f6108c libobjc.A.dylib`objc_exception_throw + 318
    frame #9: 0x00007fff8d067372 CoreFoundation`-[__NSPlaceholderArray initWithObjects:count:] + 290
    frame #10: 0x00007fff8d0eaa1f CoreFoundation`+[NSArray arrayWithObject:] + 47
  * frame #11: 0x0000000100001b54 test`main(argc=1, argv=0x00007fff5fbff808) + 68 at main.m:15
    frame #12: 0x00007fff8bea05ad libdyld.dylib`start + 1
    frame #13: 0x00007fff8bea05ad libdyld.dylib`start + 1

Le débogage de SIGABRT et EXC_BAD_INSTRUCTION se bloque

Un SIGABRT ou un EXC_BAD_INSTRUCTION signifie généralement que l'application s'est planté intentionnellement car une vérification a échoué. Ceux-ci doivent enregistrer un message sur la console du débogueur avec plus d'informations; vérifiez ici pour plus d'informations.

De nombreux SIGABRT sont causés par des exceptions Objective-C non SIGABRT . Il y a beaucoup de raisons pour lesquelles des exceptions peuvent être levées, et elles enregistrent toujours beaucoup d'informations utiles sur la console.

• NSInvalidArgumentException , ce qui signifie que l'application a transmis un argument non valide à une méthode
• NSRangeException , ce qui signifie que l'application a tenté d'accéder à un index hors limites d'un objet tel qu'un NSArray ou un NSString
• NSInternalInconsistencyException signifie qu'un objet découvert était dans un état inattendu.
• NSUnknownKeyException signifie généralement que vous avez une mauvaise connexion dans un XIB. Essayez certaines des réponses à cette question .

Déboguer EXC_BAD_ACCESS

EXC_BAD_ACCESS signifie que le processus a tenté d'accéder à la mémoire de manière non valide, par exemple en déréférençant un pointeur NULL ou en écrivant dans une mémoire en lecture seule. C'est le type de crash le plus difficile à déboguer, car il ne contient généralement pas de message d'erreur, et certains plantages peuvent être très difficiles à reproduire et / ou se produire dans un code sans rapport avec le problème. Cette erreur est très rare dans Swift, mais si cela se produit, vous pouvez souvent obtenir des blocages plus faciles à déboguer en réduisant les optimisations du compilateur.

La plupart des erreurs EXC_BAD_ACCESS sont provoquées en essayant de déréférencer un pointeur NULL . Si tel est le cas, l'adresse indiquée dans la flèche rouge sera généralement un nombre hexadécimal inférieur à une adresse mémoire normale, souvent 0x0 . Définissez des points d'arrêt dans le débogueur ou ajoutez des instructions printf / NSLog occasionnelles pour savoir pourquoi ce pointeur est NULL .

Un EXC_BAD_ACCESS qui se produit de manière moins fiable ou qui n'a aucun sens pourrait résulter d'un problème de gestion de la mémoire. Les problèmes courants qui peuvent causer ceci sont:

• Utiliser de la mémoire qui a été désallouée
• Essayer d'écrire après la fin d'un tableau C ou d'un autre type de tampon
• Utiliser un pointeur non initialisé

Dans la section Diagnostics de l'éditeur de schéma, Xcode inclut quelques outils utiles pour résoudre les problèmes de mémoire:

Le programme Sanitizer d'adresses ajoute de nombreuses vérifications qui arrêteront l'application chaque fois que des problèmes de mémoire surviennent et fournissent un message d'erreur utile détaillant exactement ce qui s'est passé. Zombie Objects détecte les problèmes liés aux objets Objective-C libérés, mais vous ne devriez pas rencontrer ce type de problèmes avec le comptage automatique des références activé.