Écrit par Reinder de Vries le 6 août 2020 dans le Développement d’applications, iOS

Une minute votre application iOS fonctionne bien dans Xcode, et la suivante, elle a désespérément s’est écrasé avec une erreur SIGABRT cryptique. Que se passe-t-il !?

Dans ce tutoriel, vous apprendrez:

• Comment résoudre l’erreur « Signal SIGABRT » dans Xcode
• Comment utiliser certains des outils de débogage dans Xcode
• Que signifie SIGABRT et quelles sont ses causes
• 3 approches pour trouver la cause première de SIGABRT

Prêt? Allons-y.

1. Que signifie « Thread 1: Signal SIGABRT »?
2. Vérifiez Vos Points de Vente
3. Vérifiez La Stacktrace
4. Créez un Point d’arrêt d’exception
5. Pour En Savoir plus

Que Signifie « Thread 1: Signal SIGABRT »?

L’erreur SIGABRT signifie « abandon du signal ». C’est un signal envoyé par iOS – le système d’exploitation – à une application en cours d’exécution, qui quittera immédiatement l’application en raison d’une erreur d’exécution. Cela signifie essentiellement que votre application s’est écrasée

Voici à quoi elle ressemble dans Xcode:

Dans la capture d’écran, vous voyez quelques choses:

• Sur la gauche, vous voyez une liste des threads qui se sont exécutés lorsque l’application s’est écrasée. Vous voyez que le thread qui a provoqué le crash est le thread principal, ou « Thread 1 ».
• Dans l’éditeur, nous voyons ce thread redouté 1: erreur de signal SIGABRT. Il a mis en évidence la ligne 12 dans l’éditeur, la définition de classe de AppDelegate.
• En bas, vous voyez une sortie de débogage utile. Dans ce cas, vous obtenez une stacktrace et un message d’erreur cryptique sur le fait de ne pas être « conforme au codage de la valeur clé ». »

Le problème avec l’erreur SIGABRT est qu’elle est trop générique. Xcode dit essentiellement: « Regardez, votre application s’est écrasée, c’est tout ce que nous savons. »Dans la plupart des cas d’erreur SIGABRT, vous obtenez peu d’informations sur la cause de l’erreur.

Avant de continuer, discutons de quelques idées fausses et pièges courants de SIGABRT:

• L’erreur SIGABRT n’a généralement rien à voir avec la déclaration de classe AppDelegate, même si elle met en évidence cette ligne dans Xcode. La ligne est mise en surbrillance car il s’agit de la première ligne de code de votre application. Ne perdez pas votre temps à regarder dans la classe AppDelegate, sauf si vous êtes absolument certain que le bogue est là.
• La stacktrace est une liste d’appels de fonction qui conduisent au plantage de l’application. Cela ne signifie pas que la ligne de code à l’origine de l’erreur se trouve n’importe où dans la stacktrace. C’est parfois le cas, mais dans d’autres cas, la stacktrace conduit simplement au code qui s’est étouffé avec une valeur que vous avez définie ailleurs dans votre propre code.
• Ne vous regardez pas aveuglément sur une erreur SIGABRT. Il y a une cause rationnelle et logique à l’erreur. C’est probablement un bogue dans votre propre code, et il n’y a rien de mal à cela. Les applications ne sont pas magiques, personne n’est à votre disposition et les bugs n’apparaissent jamais à l’improviste. Ne vous frustrez pas avec des pensées comme « Ça s’est bien passé hier!–- c’est toujours le cas, et maintenant ce n’est pas le cas!

Maintenant que nous avons établi une ligne de base, passons à la première cause de SIGABRT.

Vérifiez vos points de vente

Une cause fréquente de « Signal SIGABRT » est une faute de frappe ou un bogue dans vos points de vente. Voici ce qui s’est passé:

• Vous avez créé un nouveau contrôleur de vue dans Interface Builder et l’avez configuré avec quelques éléments d’interface utilisateur tels que des boutons et des étiquettes
• Vous avez connecté ces éléments d’interface utilisateur à votre code en utilisant les propriétés de sortie, ce qui crée une connexion entre une propriété de votre contrôleur de vue et l’élément d’interface utilisateur dans Interface Builder
• À un moment donné, vous avez changé le nom de la propriété de sortie initiale et votre application a commencé à se bloquer avec une erreur SIGABRT

Lorsque vous utilisez Interface Builder pour créer un contrôleur de vue, votre l’application utilisera le fichier XIB pour générer l’interface utilisateur du contrôleur de vue lorsque votre application fonctionne (grosso modo). À ce stade, il connectera également les prises du XIB aux propriétés de la classe view controller.

Si vous avez changé le nom d’une propriété de sortie, votre application ne la trouve plus. Et à cause de cela, il lancera une exception. Ce qui cause l’erreur SIGABRT, c’est de ne pas gérer cette exception.

Voici à quoi cela ressemble dans Xcode:

Voir ce qui se passe? La propriété est appelée otherButton, mais la sortie est toujours appelée button. À un moment donné, nous avons changé le point de vente – parce que le nouveau nom est meilleur – et avons confondu l’application, ce qui l’a fait planter.

En haut de la pile, nous repérons également un autre indice:

Terminating app due to uncaught exception 'NSUnknownKeyException', reason: ': this class is not key value coding-compliant for the key button.

Qu’est-ce que cela signifie? L’application nous indique à ce stade que le contrôleur de vue n’est pas conforme au codage de valeur de clé pour la clé button. Cela signifie qu’il ne peut pas trouver la propriété button sur le contrôleur de vue. Et c’est vrai, parce que nous l’avons renommé.

iOS utilise un mécanisme appelé codage de valeur de clé pour inspecter les propriétés d’un contrôleur de vue, de sorte qu’il peut utiliser ces propriétés pour référencer les éléments d’interface utilisateur qu’il a créés en fonction du XIB.

Comment résolvez-vous le bug à ce stade? Vous pouvez utiliser 2 approches :

1. Vous renommez la propriété à son nom d’origine
2. Vous supprimez la connexion de sortie dans Interface Builder et vous la reconnectez à l’aide du nouveau nom de propriété de sortie

Passons à autre chose !

Vérifiez la Stacktrace

Dans de nombreux cas, Xcode ne vous affichera aucun message d’erreur utile pour un plantage SIGABRT. Lorsque cela se produit, il est utile de connaître quelques commandes de débogage, telles que bt.

Xcode a un environnement de débogage intégré appelé LLDB. C’est ce que vous voyez au bas de Xcode lorsque votre application s’exécute, la Console ou la zone de sortie de débogage. Vous voyez souvent des messages de débogage ici, mais saviez-vous que vous pouvez également l’utiliser pour saisir des commandes?

La prochaine fois que votre application se bloque, essayez de taper help dans LLDB. Comme ceci:

Vous verrez que de nombreuses commandes LLDB correspondent directement aux actions que vous pouvez effectuer avec le débogueur, telles que la définition de points d’arrêt, le franchissement de lignes de code et l’inspection des valeurs d’exécution.

Une commande est particulièrement utile. Vous pouvez taper bt pour voir la pile d’appels actuelle (également appelée « backtrace » ou « stacktrace »). Ceci est une liste de toutes les fonctions qui ont fonctionné jusqu’au plantage actuel. Cette trace inclut généralement la fonction à l’origine d’un bogue.

Ici, consultez la stacktrace d’une erreur d’index hors plage typique. Dans la capture d’écran ci-dessous, nous avons délibérément causé cette erreur en obtenant index99 à partir d’un tableau qui ne contient que 4 éléments. Lorsque l’application se bloque, bt peut nous indiquer quelle ligne de code a causé l’erreur.

Pouvez-vous repérer les informations suivantes dans la stacktrace?

• Le code incriminé se trouve à la ligne 21 de ViewController.swift, à l’intérieur de la fonction viewDidLoad()

Vous pouvez même voir que nous avons utilisé l’indice « getter » de Array

• Avant le crash tout un tas de des appels de fonction liés au contrôleur de vue ont été effectués

Sur la base des informations obtenues avec bt, nous pouvons trouver la ligne incriminée dans notre code et la corriger. Xcode nous a déjà aidés dans ce cas, en mettant en évidence l’erreur dans l’éditeur. Dans certains scénarios, vous n’aurez pas une telle chance, et il peut être utile d’utiliser la commande bt.

Une dernière chose : vous pouvez inspecter les valeurs à l’exécution avec la commande print. Dans le scénario ci-dessus, taper print names aurait produit cette sortie :

() $R0 = 4 values { = "Ford" = "Arthur" = "Zaphod" = "Trillian"}

Pour imprimer des objets complexes, utilisez po. Fantastique!

Créez un point d’arrêt d’exception

Vous pouvez utiliser des points d’arrêt pour arrêter l’exécution de votre code sur une certaine ligne. À ce stade, vous pouvez ensuite inspecter les valeurs et parcourir les fonctions.

Un point d’arrêt d’exception est déclenché chaque fois qu’une exception se produit dans votre code. Au lieu de spécifier sur quelle ligne le point d’arrêt est déclenché, vous demandez au débogueur d’arrêter l’exécution du code pour les exceptions.

Les points d’arrêt d’exception sont utiles pour inspecter le code lorsqu’une exception se produit. Vous pouvez voir quelle ligne de code a déclenché l’exception et vous pouvez inspecter les valeurs de votre code à ce stade. Certaines exceptions sont causées par des bogues ou des états non valides de votre application, de sorte que les points d’arrêt d’exception sont utiles pour trouver et corriger ces bogues.

Voici comment définir un point d’arrêt d’exception:

1. Accédez au navigateur de points d’arrêt dans Xcode, en utilisant les onglets à gauche
2. Cliquez sur le bouton en bas à gauche + et choisissez Point d’arrêt d’exception
3. Laissez les paramètres par défaut tels quels (bien qu’ils soient utiles à personnaliser)
4. Exécutez votre code

Lorsqu’une exception est levée, l’exécution de votre application s’arrête. Vous pouvez maintenant utiliser le débogueur pour inspecter les valeurs, parcourir le code et utiliser les commandes LLDB. Lorsque cela est possible, Xcode vous mènera à la ligne de code à l’origine de l’exception.

Gardez à l’esprit qu’une exception ne bloque pas nécessairement votre application ! Ainsi, chaque fois que le point d’arrêt d’exception est activé et qu’une exception se produit, votre application est arrêtée. Arrêter le code avec un point d’arrêt n’est pas la même chose qu’un crash d’application, alors ne laissez pas cela vous confondre.

Par exemple, un point d’arrêt d’exception sera déclenché par une exception de contraintes non satisfaite, mais cela ne bloquera pas votre application. Utilisez le point d’arrêt d’exception pour collecter des informations supplémentaires pour le crash de SIGABRT, puis désactivez-le une fois que vous avez résolu le bogue (jusqu’à ce qu’il soit à nouveau nécessaire).

Pour en savoir plus

L’erreur SIGABRT est assez cryptique et peut s’avérer difficile à résoudre. Pourquoi Xcode ne peut-il pas simplement donner des messages d’erreur utiles? Eh bien, c’est une bonne question

La réponse courte est qu’il y a tellement de pièces mobiles dans le développement iOS que Xcode ne peut pas toujours déterminer la cause d’un crash. Xcode ne sait pas que vous avez changé par erreur le nom d’un point de vente. Il sait seulement que lors de la connexion de la prise, un code a été invoqué, ce qui a provoqué une exception.

Cela signifie que vous verrez toujours une erreur aussi proche que possible de la cause première. Le mieux que vous puissiez faire est de faire beaucoup d’erreurs, de décrypter beaucoup de messages d’erreur et de mieux les connaître. Et ce que vous avez appris dans ce tutoriel, c’est comment trouver et résoudre l’erreur SIGABRT!

Vous voulez en savoir plus ? Consultez ces ressources:

• Commencez avec le Débogage dans Xcode
• Comprendre L’Erreur « Sélecteur Non Reconnu Envoyé à l’Instance » Dans Xcode
• Comprendre L’Erreur « Néant trouvé de manière inattendue lors du déballage d’une valeur Optionnelle »
• Comprendre L’Erreur « Utilisation d’un Identifiant Non Résolu » Dans Xcode
• Erreurs Hors Ligne Dans La Programmation Swift
• Gestion Des Erreurs Dans Swift Avec Do-Try-Catch