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é.
Ouvrir des rapports d'erreur
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».
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.
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?
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?
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?
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?
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.
