Les plantages d’applications sur Mac sont généralement assez rares. Mais quand ils se produisent, vous voudrez peut-être rechercher leur cause. Et si vous êtes développeur, vous devez comprendre pourquoi votre application plante. Voici comment lire les rapports de plantage de macOS et trier le langage cryptique.
Contenu
Ouverture des rapports d’incident
Lorsqu’une application plante sur votre Mac, elle génère automatiquement un rapport de plantage. Vous verrez cela apparaître après le crash avec une boîte de dialogue d’avertissement disant « [App] a démissionné de façon inattendue. Ce rapport d’incident peut être lu immédiatement dans cette fenêtre en cliquant sur le bouton « Rapport… ». Le rapport de plantage est également disponible dans l’application Console.
1. Ouvrez l’application Console en tapant « Console » dans Spotlight ou en naviguant vers « Application -> Utilitaires -> Console.app ».
2. Cliquez sur « Rapports d’utilisateurs » dans le menu de gauche, puis cliquez sur le rapport de plantage que vous souhaitez afficher. Tous ces fichiers se termineront par « .crash » et incluront la date et l’application en panne dans le titre. Les détails du rapport d’incident sont disponibles dans le volet de droite.
Lecture des rapports de plantage macOS
Parcourons le rapport de plantage de haut en bas.
Qu’est-ce qui s’est écrasé?
La première partie du rapport de plantage vous indique quel « processus » ou application a planté. La partie la plus importante pour le dépanneur moyen est le nom du processus.
Quand s’est-il planté ?
La deuxième partie nous dit quand le crash s’est produit. Il fournit également quelques informations sur votre système.
Qu’est-ce qui a causé le crash?
La partie suivante est la plus éclairante. Le « type d’exception » fourni par l’application nous indique la cause du crash. Le journal indique également quel thread s’est écrasé : dans ce cas, le thread 0.
Apple répertorie certains types d’exceptions courants dans sa documentation technique :
Comme nous pouvons le voir dans notre rapport de plantage, l’application a tenté d’accéder à la mémoire non mappée. Cela est dû à une erreur de programmation dans l’application ou à un état utilisateur inhabituel provoquant une mauvaise cartographie de la mémoire par l’application.
Qu’est-ce qui a conduit au crash ?
Après cela, nous voyons une liste chronologique inversée de ce qui a conduit au crash. Ceux-ci sont triés par thread, en commençant par le thread 0.
Il y a quatre colonnes dans ce rapport. Le premier rapporte le numéro de l’événement dans l’ordre chronologique inverse, en commençant à 0. Le second est l’identifiant du processus. La troisième est l’adresse du processus en mémoire. Le quatrième est le nom de la tâche du programme.
Ce « backtrace » peut être quelque peu déconcertant. C’est « symbolisé », ce qui signifie que certaines des adresses mémoire ont été remplacées par des noms de fonctions ou des tâches d’application. Parfois, cela ne peut pas être fait complètement, laissant des adresses mémoire illisibles dispersées dans le rapport.
Nous le voyons dans le rapport de plantage ci-dessus : com.trankynam.aText n’est pas symbolisé. Même avec une symbolisation complète, il peut être difficile de lire la trace. Parfois, les développeurs incluent des notes utiles sur les tâches et les événements de l’application. D’autres fois, ce sont des titres cryptiques ou un code numérique. Si vous pouvez donner un sens à la symbolique, vous pourrez peut-être comprendre ce qui se passe. Mais il est tout aussi possible que vous ayez besoin d’avoir codé l’application vous-même pour donner un sens au backtrace.
Conclusion : est-ce utile ?
Si vous êtes développeur, la lecture des rapports de plantage est essentielle. Il vous aide à comprendre quelle partie de votre application plante et pourquoi. Si vous êtes un utilisateur, ils ne sont pas aussi utiles. Mais si vous rencontrez un plantage persistant, les rapports de plantage peuvent vous aider à résoudre le problème ou à travailler avec le développeur pour résoudre le problème. Vous pourriez obtenir un code d’erreur utile pour Google ou être en mesure de fournir au support technique les bonnes informations. Si vous voulez les détails sanglants, vous pouvez tout lire à ce sujet dans la note technique d’Apple sur les plantages.
Cet article est-il utile ? Oui Non
