Este artículo se centra en los informes de fallos de macOS. Más específicamente, este artículo explica cómo puede (1) localizar registros de fallas (2) y leerlos para diagnosticar una falla.
Su Mac puede fallar, en raras ocasiones. Estos choques generalmente no significan nada importante, si es que es raro. Por lo tanto, no es algo de lo que deba preocuparse. En la mayoría de los casos, reiniciar su Mac resolverá el problema. Tu Mac se reiniciará automáticamente.
Sin embargo, si su Mac se bloquea con frecuencia, es posible que desee averiguar por qué ocurren estos bloqueos para poder evitar que vuelvan a ocurrir. Y lo más importante que debe hacer es encontrar detalles de error más específicos.
En este artículo, veremos cómo usar los registros de fallas que genera su sistema. Estos registros lo ayudarán a identificar qué está causando el bloqueo.
Consulte también: Cómo utilizar la utilidad de red en Mac
Dónde encontrar informes de fallos
Hay dos formas de acceder a sus informes de fallos. Puede utilizar cualquiera de los métodos:
-
Puede utilizar la aplicación de consola. La aplicación de consola incluida con su Mac. Puede abrir esta aplicación yendo a Aplicaciones> Utilidades> Consola. También puede utilizar Spotlight para acceder a la consola. Seleccione su dispositivo y haga clic en Informes de fallos en la sección “informes”.
También puede encontrar sus informes de fallos en ~ / Library / Logs / DiagnosticReports /. Así es como puede acceder allí:
-
Vaya al Finder Ahora presione la tecla Opción y luego haga clic en Ir (mientras está presionando la tecla Opción) Haga clic en Biblioteca Haga clic en la carpeta Registros Haga clic en la carpeta DiagnosticReports Y abra el archivo que dice “Crash”
Consulte también: Reinicie su Mac en modo seguro
Cómo leer los informes de fallos de macOS
Comprender estos informes puede resultar difícil, ya que suelen ser grandes. Así es como puede descifrar un informe de fallos:
1. La primera sección de un informe de fallos incluye qué proceso falló. Algo como esto:
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
En este caso, dicho proceso es WebKit (Safari).
2. La siguiente sección de un informe de fallos incluye la fecha / hora y el sistema operativo, como este:
Date/Time: 2019-10-26 10:25:58.412 +0300 OS Version: Mac OS X 10.15 (19A583) Report Version: 12
3. La siguiente sección incluye más detalles del bloqueo (La excepción), algo como esto:
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000004 Exception Note: EXC_CORPSE_NOTIFY
Hay cuatro tipos de excepciones comunes, según Apple:
EXC_BAD_ACCESS / KERN_INVALID_ADDRESS: esto se debe a que el subproceso accede a la memoria no asignada. Puede activarse mediante un acceso a datos o una búsqueda de instrucciones; la sección Estado del hilo describe cómo diferenciar.
EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE: esto se debe a que el hilo intenta escribir en la memoria de solo lectura. Esto siempre se debe a un acceso a datos.
EXC_BAD_INSTRUCTION: esto se debe a que el subproceso ejecuta una instrucción ilegal.
EXC_ARITHMETIC / EXC_I386_DIV: esto se debe a que el hilo divide un entero por cero en una computadora con procesador Intel.
La siguiente sección incluye información de seguimiento. Puede haber uno o varios subprocesos. En orden cronológico inverso, cada hilo muestra la serie de eventos.
Para comprender esta sección, busque el hilo que falló. Puede encontrarlo fácilmente, porque el informe dirá algo como esto: Subproceso (número de subproceso) bloqueado. Esta sección explica qué provocó el accidente.
Como esto:
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
Aquí hay cuatro columnas:
El primero es el número de fotograma (cronológico inverso), como 0, 1, 2, 3…. El segundo es el nombre del programa u otro proceso que realizó la tarea. En este caso, com.apple.WebKit. La tercera columna es la dirección del programa del contador. La cuarta columna es la tarea.
A partir de este ejemplo, sabemos que, por ejemplo, “com.apple.WebCore 0x00007fff3e26977a WebCore :: HTMLMediaElement :: mediaCanStart (WebCore :: Document &) + 90” es responsable del bloqueo.
Ahora sabe qué causó el accidente y una serie de eventos lo desencadenó. Esto lo ayudará a identificar el problema y luego abordarlo de manera apropiada.
Si su problema es una aplicación de terceros, es posible que desee ponerse en contacto con su desarrollador. Cuénteles su problema y le recomendamos enviar una copia de este registro de fallas. Puede hacer clic en el icono de compartir en la aplicación de la consola para enviar el informe.
Ver también:
