Recherche sur le site Web

Rapports de plantage : comment les utiliser pour résoudre les problèmes de votre Mac.

Cet article se concentre sur les rapports de plantage macOS. Plus précisément, cet article explique comment vous pouvez (1) localiser les journaux de plantage (2) et les lire pour diagnostiquer un plantage.

Votre Mac peut planter, mais c'est rare. Ces plantages ne signifient généralement rien d'important, s'ils sont rares. Donc, ce n'est pas quelque chose dont vous devriez vous inquiéter. Dans la plupart des cas, redémarrer votre Mac résoudra le problème. Votre Mac redémarrera automatiquement.

Cependant, si votre Mac plante fréquemment, vous voudrez peut-être déterminer pourquoi ces plantages se produisent afin de pouvoir les éviter à l'avenir. Et la chose la plus importante à faire est de trouver des détails d'erreur plus spécifiques.

Dans cet article, nous allons examiner l'utilisation des journaux de plantage que votre système génère. Ces journaux vous aideront à identifier ce qui cause le plantage.

Voir aussi : Comment utiliser l'outil Réseau sur Mac

Où trouver les rapports d'accident

Il y a deux façons d'accéder à vos rapports de plantage. Vous pouvez utiliser l'une des méthodes :

    2. Vous pouvez utiliser l'application Console. L'application Console est incluse avec votre Mac. Vous pouvez ouvrir cette application en allant dans Applications > Utilitaires > Console. Vous pouvez également utiliser Spotlight pour accéder à la Console. Sélectionnez votre appareil et cliquez sur Rapports de plantage dans la section 'rapports'.

  2. Vous pouvez également trouver vos rapports d'accidents dans ~/Library/Logs/DiagnosticReports/. Voici comment y accéder :

    1. Allez dans le Finder
    2. Maintenant, appuyez sur la touche Option, puis cliquez sur Go (tout en maintenant la touche Option enfoncée)
    3. Cliquez sur la bibliothèque
    4. Cliquez sur le dossier des journaux
    5. Cliquez sur le dossier DiagnosticReports

    6. Et ouvrez le fichier qui dit « Crash ».

Voir aussi : Redémarrez votre Mac en mode sans échec

Comment lire les rapports de plantage de macOS

Comprendre ces rapports peut être difficile car ils sont généralement volumineux. Voici comment vous pouvez déchiffrer un rapport d'accident :

1. La première section d'un rapport de crash indique quel processus a échoué. Quelque chose comme ceci :

Process: com.apple.WebKit.WebContent [6929]
Path: /System/Library/Frameworks/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc/Contents/MacOS/com.apple.WebKit.WebContent
Identifier: com.apple.WebKit.WebContent
Version: 15608 (15608.2.30.1.1)
Build Info: WebKit2-7608002030001001~1
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Safari [509]
User ID: 501

Dans ce cas, le processus en question est WebKit (Safari).

2. La section suivante d'un rapport d'accident inclut la date/l'heure et le système d'exploitation, comme ceci :

Date/Time: 2019-10-26 10:25:58.412 +0300
OS Version: Mac OS X 10.15 (19A583)
Report Version: 12

3. La section suivante comprend plus de détails sur le plantage (L'Exception), quelque chose comme ceci :

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000004
Exception Note: EXC_CORPSE_NOTIFY

Il existe quatre types d'exceptions courants, selon Apple :

EXC_BAD_ACCESS/KERN_INVALID_ADDRESS — Cela est causé par le fil d'exécution accédant à de la mémoire non mappée. Cela peut être déclenché soit par un accès aux données, soit par une récupération d'instructions; la section État du fil décrit comment faire la distinction.

EXC_BAD_ACCESS/KERN_PROTECTION_FAILURE — Cela est causé par le fil essayant d'écrire dans de la mémoire en lecture seule. Cela est toujours causé par un accès aux données.

EXC_BAD_INSTRUCTION — Ceci est causé par le fil exécutant une instruction illégale.

EXC_ARITHMETIC/EXC_I386_DIV — Cela est causé par le fil effectuant une division entière par zéro sur un ordinateur basé sur Intel.

La section suivante inclut des informations sur la trace arrière. Il peut y avoir un ou plusieurs fils d'exécution. Par ordre chronologique inversé, chaque fil montre la série d'événements.

Pour comprendre cette section, trouvez le fil qui a planté. Vous pouvez facilement le trouver, car le rapport indiquera quelque chose comme ceci : Fil (numéro du fil) a planté. Cette section explique ce qui a conduit au plantage.

Comme ceci :

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.WebCore 0x00007fff3e26977a WebCore::HTMLMediaElement::mediaCanStart(WebCore::Document&) + 90
1 com.apple.WebCore 0x00007fff3cda7057 WebCore::Page::setCanStartMedia(bool) + 343
2 com.apple.JavaScriptCore 0x00007fff32be97eb WTF::RunLoop::TimerBase::timerFired(__CFRunLoopTimer*, void*) + 27
3 com.apple.CoreFoundation 0x00007fff2e585ff6 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
4 com.apple.CoreFoundation 0x00007fff2e585bb0 __CFRunLoopDoTimer + 872
5 com.apple.CoreFoundation 0x00007fff2e5855c3 __CFRunLoopDoTimers + 317
6 com.apple.CoreFoundation 0x00007fff2e566860 __CFRunLoopRun + 2227
7 com.apple.CoreFoundation 0x00007fff2e565d38 CFRunLoopRunSpecific + 503
8 com.apple.Foundation 0x00007fff30c26cad -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
9 com.apple.Foundation 0x00007fff30c26bc6 -[NSRunLoop(NSRunLoop) run] + 76
10 libxpc.dylib 0x00007fff65b809d6 _xpc_objc_main.cold.4 + 49
11 libxpc.dylib 0x00007fff65b697e1 _xpc_objc_main + 559
12 libxpc.dylib 0x00007fff65b692fc xpc_main + 377
13 com.apple.WebKit 0x00007fff3f2fbeef WebKit::XPCServiceMain(int, char const**) + 539
14 libdyld.dylib 0x00007fff65916405 start + 1

Il y a quatre colonnes ici :

  • Le premier est le numéro de cadre (en ordre chronologique inversé), comme 0, 1, 2, 3….
  • Le second est le nom du programme ou d'un autre processus qui a effectué la tâche. Dans ce cas, com.apple.WebKit.
  • La troisième colonne est l'adresse du programme de compteur.
  • La quatrième colonne est la tâche.

D'après cet exemple, nous savons que, par exemple, « com.apple.WebCore 0x00007fff3e26977a WebCore::HTMLMediaElement::mediaCanStart(WebCore::Document&) + 90 » est responsable du plantage.

Maintenant, vous savez ce qui a causé l'accident et la série d'événements qui ont déclenché l'accident. Cela vous aidera à identifier le problème et à y remédier de manière appropriée.

Si votre problème concerne une application tierce, vous voudrez peut-être contacter son développeur. Expliquez-leur votre problème et vous voudrez peut-être envoyer une copie de ce journal d'erreurs. Vous pouvez cliquer sur l'icône de partage dans l'application Console pour envoyer le rapport.

Voir aussi :

  • Comment réinitialiser les paramètres réseau sur Mac
  • L'application Mail continue de planter et ne s'ouvre pas ; Corrigez ça.

Articles connexes