Comment lire les rapports d'incidents Mac OS pour le dépannage

Désactive les applications sur votre Mac sont très rares. Mais quand cela arrive, vous voudrez peut-être suivre ces problèmes. Si vous êtes un développeur, vous devez comprendre pourquoi votre application échoue. Voici comment lire les rapports d'erreur des macros et les trier dans un langage crypté.

Mac | Lire les rapports de crash sur Mac OS 1 | lire les rapports d'accident, héros DzTechs

Ouvrir des rapports d'erreur

Mac | Lire les rapports de crash sur Mac OS 2 | comment lire les rapports d'accident 1 DzTechs

Lorsqu'une application se bloque sur un Mac, elle génère automatiquement un rapport d'erreur. Vous verrez ceci apparaître après le crash à travers une boîte de dialogue d'avertissement disant "[Application] s'est arrêté de façon inattendue." Ce rapport d'accident est disponible pour une lecture immédiate dans cette fenêtre en cliquant sur le bouton "Rapport ...". Le rapport d'erreur peut également être trouvé dans l'application Console.

1. Ouvrez l'application Console en tapant «Console» dans Spotlight ou allez dans «Application -> Utilities -> Console.app».

Mac | Lire les rapports de crash sur Mac OS 3 | comment lire les rapports d'accident 2 DzTechs

2. Cliquez sur Rapports utilisateur dans le menu de gauche, puis cliquez sur le rapport de blocage que vous souhaitez afficher. Tous ces fichiers se terminent par ".crash" et incluent la date et l'application endommagées dans l'adresse. Les détails du rapport de panne sont disponibles dans le volet de gauche.

Mac | Lire les rapports de crash sur Mac OS 4 | console lire les rapports de crash 2 e1521219301577 DzTechs

Lire les rapports d'incidents de Mac OS

Regardons à travers le rapport d'accident de haut en bas.

Qu'est-ce qui ne va pas?

Mac | Lire les rapports de crash sur Mac OS 5 | console lire les rapports de crash 3DzTechs

La première partie du rapport d'erreur vous montre qui "bloque" un processus ou une application. La partie la plus importante de l'outil de dépannage est le nom du processus.

Process: aText [11473]

Path: /Applications/aText.app/Contents/MacOS/aText

Identifier: com.trankynam.aText

Version: 2.19 (62)

Code Type: X86-64 (Native)

Parent Process: ??? [1]

Responsible: aText [11473]

User ID: 501

Quand les vacances ont-elles eu lieu?

Mac | Lire les rapports de crash sur Mac OS 6 | console lire les rapports de crash 4DzTechs

La deuxième partie nous dit quand les vacances se sont produites. Il fournit également peu d'informations sur votre système.

Date/Time: 2018-03-15 00:58:10.552 -0400

OS Version: Mac OS X 10.12.6 (16G1036)

Report Version: 12

Anonymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090

 

Time Awake Since Boot: 630000 seconds

 

System Integrity Protection: enabled

Qu'est-ce qui a causé la panne?

Mac | Lire les rapports de crash sur Mac OS 7 | console lire les rapports de crash 5DzTechs

La partie suivante est la plus légère. Le "type d'exception" fourni par l'application nous dit pourquoi. En outre, le journal indique également quel thread a généré le blocage: Dans ce cas, le thread est 0.

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

 

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0

Exception Note: EXC_CORPSE_NOTIFY

 

Termination Signal: Segmentation fault: 11

Termination Reason: Namespace SIGNAL, Code 0xb

Terminating Process: exc handler [0]

Listes Apple Quelques types d'exception courants Dans sa documentation technique:

mémoire médiocre (EXC_BAD_ACCESS / SIGSEGV / SIGBUS) - le programme tente d'accéder à la mémoire de manière incorrecte ou en utilisant une adresse non valide. Avec le code expliquant le problème de mémoire.

Sortie anormale (EXC_CRASH / SIGABRT) - sortie anormale, généralement à la main d'une exception C ++ sans attente et d'un appel à abort ()

Trap Trace (EXC_BREAKPOINT / SIGTRAP) - comme SIGABRT, mais cette terminaison donne un processus de débogueur attaché d'opportunité est interrompue lorsqu'une erreur de suivi point d'arrêt.

Orientation illégale (EXC_BAD_INSTRUCTION / SIGILL) - Le traitement a produit un traitement qui n'a pas été compris ou n'a pas pu être traité.

Quitter (SIGQUIT) - Le processus a été terminé par un autre processus avec des privilèges suffisants. Généralement, le processus de surveillance met fin au processus de faute professionnelle.

Termination (SIGKILL) - Le processus a été arrêté à la demande du système. Le code de sortie sera ajouté à l'exception.

Comme nous le voyons à partir du rapport d'accident, l'application a essayé d'accéder à la mémoire non isolée. Cela est dû à une erreur de programmation dans l'application ou à un état utilisateur inhabituel qui entraîne une mauvaise configuration de la mémoire.

Quelles sont les causes des vacances?

Mac | Lire les rapports de crash sur Mac OS 8 | console lire les rapports de crash 6DzTechs

Ensuite, nous voyons une liste chronologique inverse de ce qui provoque l'effondrement. Ceux-ci sont triés par thread, à partir d'un thread 0.

Il y a quatre colonnes pour ce rapport. Les premiers rapports se réfèrent au numéro de l'événement dans l'ordre chronologique inverse, en commençant par 0. Le second est l'identifiant du processus. Le troisième est l'adresse de processus en mémoire. Le quatrième est le nom de la tâche du programme.

Cette «retraite» peut être quelque peu déroutante. Il est "symbolique", ce qui signifie que certaines adresses mémoire ont été remplacées par des noms de fonctions ou des tâches d'application. Parfois, cela ne peut pas être complètement fait, laissant les adresses de mémoire illisibles dispersées dans le rapport.

Nous voyons cela dans le rapport de crash ci-dessus: com.trankynam.aText n'est pas symbolique. Même avec des codecs complets, la lecture de l'arrière-plan peut être difficile. Les développeurs incluent parfois des notes utiles sur les tâches et les événements de l'application. À d'autres moments, ce sont des adresses cryptées ou un code numérique. Si vous pouvez comprendre le symbolisme, vous pouvez peut-être comprendre ce qui se passe. Mais dans la mesure du possible, vous devrez encoder l'application vous-même pour comprendre la trace.

Conclusion: était-ce utile?

Si vous êtes un développeur, il est nécessaire de lire les rapports d'erreur. Cela vous aide à comprendre quelle partie de votre application cause des problèmes et pourquoi. Si vous êtes un utilisateur, ils ne sont pas utiles. Mais si vous avez un plantage persistant, les rapports d'erreur peuvent vous aider à résoudre les problèmes et à travailler avec le développeur pour résoudre le problème. Vous pouvez obtenir une solution de code d'erreur utile de Google ou vous pouvez lui fournir un support technique. Si vous voulez des détails radicaux, vous pouvez tout lire sur eux dans Notez le dépannage technique d'Apple.

DzTech

Je suis ingénieur d'état avec une vaste expérience dans les domaines de la programmation, de la création de sites internet, du référencement et de la rédaction technique. Je suis passionné par la technologie et me consacre à fournir des informations de qualité au public. Je peux devenir une ressource plus précieuse pour les utilisateurs qui recherchent des informations précises et fiables sur les critiques de produits et les applications spécialisées dans divers domaines. Mon engagement inébranlable envers la qualité et l’exactitude garantit que les informations fournies sont dignes de confiance et utiles au public. La recherche constante de connaissances me pousse à me tenir au courant des dernières évolutions technologiques, en veillant à ce que les idées partagées soient véhiculées de manière claire et accessible.
Aller au bouton supérieur