Finder s’est arrêté de façon inattendue. Mais pourquoi ?
Les rapports de plantage peuvent donner des indices sur la raison pour laquelle une application s’est plantée sous macOS. Voici comment comprendre ce que ces rapports disent réellement sur votre Mac.
Vous avez probablement vu une alerte du Finder lorsqu’une application se ferme de manière inattendue sur votre Mac.
Connues dans le monde de la programmation sous le nom de”crash”, ces erreurs se produisent généralement lorsqu’un mauvais morceau de code s’exécute et que le système ou le processeur ne peut pas l’exécuter. Ils peuvent également se produire si une application tente d’accéder à une version manquante ou obsolète d’une bibliothèque ou d’un framework et ne peut pas exécuter un morceau de code nécessaire.
Lorsque macOS affiche l’une de ces alertes de plantage, vous pouvez soit cliquer sur le bouton”Ignorer”, soit cliquer sur le bouton”Signaler”.
Si vous cliquez sur le bouton”Signaler”, le Finder affiche une fenêtre avec le rapport de plantage et un bouton”Envoyer à Apple”. Vous devez envoyer le rapport à Apple si c’est un logiciel Apple qui a causé l’erreur.
Chaque rapport de plantage est stocké dans un fichier.ips dans le dossier”DisagnosticReports”dans votre dossier utilisateur à/Users/~/Library/Logs/
Vous pouvez également afficher et ouvrir ces rapports dans l’application Console d’Apple en sélectionnant l’élément”Rapports d’incident”sur le côté gauche de la fenêtre de la console, en sélectionnant un rapport dans le côté droit de la fenêtre, puis en Ctrl-clic ou en cliquant avec le bouton droit sur le rapport et en sélectionnant”Révéler dans le Finder”dans le menu contextuel.
Cela ouvre le dossier DiagnosticReports dans le Finder, révélant tous les fichiers de rapport de plantage enregistrés. Ces rapports ne sont conservés par macOS que pendant une durée limitée, puis il commence automatiquement à supprimer les rapports les plus anciens en premier.
Il existe également un élément de menu”Déplacer vers la corbeille”dans le menu contextuel de la console si vous souhaitez déplacer les fichiers de rapport de plantage sélectionnés vers la corbeille.
Si vous double-cliquez sur un fichier.ips dans le Finder, il le rouvre simplement dans l’application Console. Si vous Ctrl-cliquez sur un fichier.ips dans le Finder et sélectionnez”Ouvrir avec”, puis”TextEdit”dans le menu contextuel, vous pouvez également ouvrir le fichier.ips dans TextEdit.
Sachez que le texte de chaque rapport stocké dans un fichier.ips est au format JSON , vous devrez donc être capable de lire JSON pour le comprendre.
Lire les rapports de plantage dans la console
Dans tous les cas, si vous sélectionnez un rapport de plantage dans la console, vous pouvez lire son texte dans le volet de texte principal ci-dessous it :
Regardons les premiers champs d’un rapport de plantage.”Processus”sous UNIX signifie une application en cours d’exécution. Les champs sont :
Processus-le nom de l’application ou du processus. Chemin-où le fichier binaire de l’application réside sur le disque. Identifiant-généralement le nom du binaire ou du bundle, mais pas toujours. Version-la version binaire ou ??? si inconnu. Type de code-Intel ou Apple Silicon.”Universel”si les deux. Processus parent-le binaire ou l’application qui a lancé ce processus. ID utilisateur-l’ID UNIX ou le PID du processus-le même ID de processus que celui indiqué dans Terminal.
Ensuite, nous avons la date/heure, la version du système d’exploitation, la version du rapport et un UUID unique pour ce rapport. Il existe également un ID veille/veille unique.
Le rapport indique également si la protection de l’intégrité du système est activée ou non.
Ensuite, le rapport répertorie les détails du crash lui-même. Ces informations peuvent être assez techniques et sont généralement destinées aux programmeurs ou à Apple afin de retracer où le problème s’est produit dans le code de l’application afin qu’il puisse être résolu.
Habituellement, le numéro de thread qui s’est écrasé sera répertorié-dans ce cas, le premier thread-thread 0. Considérez un thread comme un chemin de code s’exécutant indépendamment d’un autre code. Sur les systèmes CPU multicœurs, chaque cœur peut avoir un ou plusieurs threads en cours d’exécution avec tous les cœurs exécutés en parallèle si nécessaire. C’est ce qu’on appelle le calcul parallèle.
Ensuite, le type de plantage ou d’exception est répertorié :
Type d’exception : EXC_CRASH (SIGABRT)
Dans ce cas, SIGABRT-le signal UNIX à abandonner, ou tuer, le fil a été envoyé. Les signaux sont des messages qu’UNIX envoie aux processus en cours d’exécution à un niveau bas pour leur dire de faire quelque chose-dans ce cas, de quitter.
Plus d’informations sur les signaux UNIX et leur fonctionnement sont disponibles en ligne.
Viennent ensuite les codes d’exception, le cas échéant, mais ceux-ci sont souvent nuls.
Le”0x”avant chaque code signifie que la valeur du code est en hexadécimal ou”hex”au lieu de décimal. L’hexadécimal est un système de numération en base 16-avec seize valeurs au lieu de dix comme le système de numération décimale. Hex utilise 0-9 puis A-F comme valeurs supplémentaires.
Vous pouvez lire sur le fonctionnement du système de nombres hexadécimaux dans n’importe quel bon livre sur le langage de programmation C.
Vient ensuite la raison de la résiliation, qui est généralement une description en anglais de ce qui a causé le crash. Dans ce cas”espace de noms DYLD, bibliothèque de code 1 manquante”.
DYLD est le chargeur dynamique-la partie du système d’exploitation qui charge dynamiquement le code en mémoire à partir du disque lorsqu’il doit être exécuté. Vous pouvez en savoir plus sur DYLD dans Terminal en tapant man dyld et en appuyant sur Retour.
Les espaces de noms sont des conventions de dénomination utilisées dans certains langages de programmation pour isoler des sections de code d’autres codes.”Code 1 Library missing”signifie que DYLD a essayé de charger une bibliothèque liée dynamiquement mais n’a pas pu.
En programmation, les bibliothèques sont des ensembles de code. Les bibliothèques peuvent être soit statiques (liées à une application au moment de la construction), soit dynamiques (chargées dans une application au moment de l’exécution).
Si l’erreur est une erreur de chargement DYLD, la ligne suivante nous indique de quelle bibliothèque il s’agissait et où elle se trouve sur le disque :
“Bibliothèque non chargée : @rpath/VBoxRT. dylib”
Dans ce cas, VBoxRT.dylib est une bibliothèque dynamique (.dylib) pour l’application Virtual Box d’Oracle. DYLD a recherché la bibliothèque dynamique VBoxRT.dylib mais ne l’a pas trouvée. L’application n’a donc pas pu s’exécuter et a reçu le signal SIGABRT pour lui dire de quitter.
Les applications pour macOS et iOS sont en fait composées de plusieurs composants-généralement un dossier appelé Bundle
Dans cet exemple, nous pouvons voir le fichier binaire de l’application dans le dossier MacOS à l’intérieur du contenu dossier dans l’app bundle :
Il existe également un dossier Bibliothèques, puis les deux Bibliothèques Apple Silicon et Intel x86 dans des dossiers au format.dylib pour les deux architectures de plate-forme Mac. Ils sont chargés au moment de l’exécution selon les besoins de DYLD.
Certains ensembles d’applications peuvent être assez simples, d’autres très complexes. Le code et les autres ressources peuvent être stockés ailleurs, en dehors des bundles d’applications.
Dans l’exemple ci-dessus, un.dylib est stocké en externe et devrait normalement être chargé en cas de besoin lors de l’exécution. Les.dylibs sont généralement des binaires uniques au lieu de bundles.
Il existe également une prise en charge dans iOS et macOS pour les Frameworks, qui sont des bundles contenant du code et d’autres ressources. Vous pouvez jeter un coup d’œil à l’intérieur des frameworks dans le Finder de la même manière que vous pouvez regarder à l’intérieur des bundles d’applications à l’aide du menu contextuel mentionné ci-dessus. Les frameworks ont toujours un numéro de version dans leurs bundles.
Les frameworks peuvent être stockés dans des bundles d’applications, ou dans/Library/Frameworks et/user/~/Library/Frameworks. Une grande partie de macOS et iOS eux-mêmes sont implémentés en tant que frameworks chargeables dynamiquement.
Apple propose un guide de programmation Framework pour développeurs qui décrit en détail le processus de chargement et de liaison pour le code macOS et iOS. La connexion de deux morceaux de code statiquement liés est appelée liaison, plutôt que liaison, et se fait lorsqu’une application est construite avec un compilateur.
Le code statique est chargé en même temps, ce qui peut consommer plus de mémoire système.
Apple a également un document de développeur distinct qui détaille les runtimes Objective-C et Swift, qui contiennent tous deux des informations supplémentaires sur la façon dont le code est chargé lors de l’exécution de l’application.
Le chargement de code dynamique remonte à la fin des années 1970 avec des langages tels que SmallTalk. Sur les plates-formes d’Apple, cela est survenu à la suite de l’achat de NeXT par Apple en 1997-et avec lui, de l’acquisition du langage de programmation Objective-C de NeXT qui a été le pionnier de l’utilisation de la liaison dynamique et de introspection.
NeXTStep Developer-l’un des premiers packages de développement à utilisez la liaison dynamique.
Aujourd’hui, les logiciels Apple sont toujours écrits soit en Objective-C, soit en Swift d’Apple, qui utilise également la liaison et le chargement dynamiques.
Le chargement dynamique permet aux applications d’avoir une plus petite empreinte mémoire puisque tout le code et les ressources d’une application n’ont pas besoin d’être chargés en mémoire en même temps. L’inconvénient du chargement dynamique est qu’il est parfois plus lent, car les ressources doivent être chargées à partir du disque pendant qu’une application est en cours d’exécution.
C’est l’une des raisons courantes du tristement célèbre curseur de beachball tournant de macOS.
Ensuite, dans le rapport de plantage, on nous indique quel processus appelant ou code binaire a appelé le code incriminé, répertorié sous”Referenced from :”. Dans ce cas, il s’agissait du principal binaire de l’application VirtualBox stocké dans le bundle de l’application.
La dernière information lisible en anglais est”Reason :”, qui tente de fournir une raison lisible par l’homme pour laquelle le crash s’est produit :
“‘/usr/lib/VBoxRT.dylib'(aucun fichier de ce type, pas dans le cache dyld), (la politique de sécurité n’autorise pas l’extension du chemin @)
(terminé au lancement ; ignorer la trace arrière)”.
Cela signifie que la bibliothèque nécessaire aurait dû se trouver dans/usr/lib/VBoxRT.dylib sur le disque mais ne l’était pas (elle y est généralement placée par le programme d’installation de VirtualBox au moment de l’installation), DYLD n’avait pas été chargé auparavant et l’application a été tuée au lancement.
Donc, pour résumer, dans l’exemple ci-dessus, VirtualBox a été lancé mais une bibliothèque dynamique requise introuvable, il a donc été tué par macOS et il s’est arrêté. Toutes les informations ont été collectées et ajoutées au rapport de crash.
Informations supplémentaires sur la console et traces de pile
Le reste des informations du rapport de plantage est encore plus technique, nous n’entrerons donc pas dans tous les détails ici , mais il y a certaines choses que vous pouvez lire rapidement pour déterminer ce qui s’est passé.
En particulier, vous pouvez suivre l’exécution du code de l’application, dans l’ordre inverse répertorié sous chaque numéro de thread, pour rechercher des indices sur la raison du crash. Tous les plantages ne sont pas liés à des bibliothèques manquantes, il est donc possible que l’application se soit lancée correctement, mais il y avait simplement une erreur de programmation dans le code qui a provoqué un plantage.
Parfois, un programmeur commettra l’erreur d’appeler un code système qui n’existe pas ou qui a modifié ses paramètres de fonction. Ou il peut s’agir d’une erreur d’accès à la mémoire ou d’un écrasement de variables dans le code avec trop de données, ce qui écrase généralement quelque chose d’important en mémoire adjacent.
Toutes ces erreurs peuvent provoquer un plantage.
Ces informations sont normalement répertoriées immédiatement après la section”Raison :”et comportent généralement une liste d’appels de fonction numérotés, avec leurs noms, leurs adresses en mémoire et la manière dont ils ont été chargés. Notez que dans cette section, vous souhaitez lire la liste des fonctions (appelée la trace de la pile), dans l’ordre inverse-de bas en haut.
C’est l’ordre dans lequel les fonctions sont réellement exécutées.
Dans ce cas, la pile est très courte et se compose principalement de signaux de préparation DYLD et d’arrêt/abandon puisque la bibliothèque nécessaire n’a pas pu être chargée au lancement. Mais certaines erreurs peuvent avoir des piles assez complexes.
Habituellement, la dernière fonction en haut (à la fin) de la pile est celle qui a causé le problème-mais pas toujours.
Savoir cela peut être utile pour diagnostiquer les plantages puisque la pile peut vous indiquer l’appel de fonction exact qui a échoué. Vous pouvez ensuite rechercher le nom de cette fonction dans la documentation des développeurs d’Apple pour obtenir plus d’indices sur ce qui s’est passé.
Parfois, le nom du framework ou de la bibliothèque contenant la fonction de plantage sera répertorié dans la trace de la pile, ce qui fournit encore plus d’informations.
Après le bloc de pile dans le rapport de plantage se trouvent des informations sur l’état du thread, qui ne sont pas vraiment pertinentes à moins que vous ne soyez un développeur, suivies du processeur sur lequel le thread s’exécutait, d’un code d’erreur le cas échéant, et un numéro de piège. Les interruptions sont des points d’insertion dans le code du système d’exploitation qui sont appelés lorsqu’un événement se produit.
Mémoire de plantage et résumés
Ensuite, il y a quelques informations sur les binaires (code compilé) impliqués dans le plantage-et ce sont généralement, mais pas toujours, les mêmes informations que celles répertoriées en haut du rapport d’incident.
Après cela, il y a un résumé des modifications externes-des résumés des ID de processus qui ont interagi avec ce processus, et des informations sur la mémoire virtuelle (VM) sur les parties de code qui étaient en mémoire et celles qui étaient encore sur le disque. La mémoire virtuelle fait référence à l’espace disque que le système d’exploitation utilise comme s’il s’agissait d’une vraie RAM afin d’augmenter la mémoire totale disponible utilisée par le système.
Ensuite, il y a des informations sur le”type de région”qui résument des informations supplémentaires sur la pile, la machine virtuelle, les segments de lien et de texte, et DYLD et la mémoire partagée. Vous pouvez généralement ignorer ces informations, sauf si vous êtes un développeur.
À la fin de chaque rapport de plantage, il y a une section”Rapport complet”, qui est essentiellement un vidage JSON brut complet de l’intégralité du fichier.ips au format texte. Le JSON brut contient des informations supplémentaires non affichées dans la fenêtre de la console, telles que l’ID de modèle Apple Mac, le type de processeur, la signature de code et d’autres informations.
Sachez également qu’une application peut avoir plusieurs threads en cours d’exécution, donc un résumé similaire à celui ci-dessus sera répertorié pour chaque thread. Mais généralement, le numéro de thread en panne est répertorié tout en haut du rapport afin que vous sachiez quel numéro de thread consulter.
Tout cela peut sembler accablant pour le nouveau venu, mais une fois que vous maîtrisez la lecture des rapports de plantage, vous pouvez généralement comprendre rapidement et facilement ce qui s’est passé-et si vous pouvez faire quelque chose à ce sujet. Dans l’exemple ci-dessus, étant donné qu’une bibliothèque requise manquait, une simple réinstallation de l’application à l’aide de son programme d’installation serait de mise.
Apple fournit un Guide de l’utilisateur de la console détaillé en ligne, qui est assez informatif et utile.
