Los bloqueos de aplicaciones en la Mac son generalmente bastante raros. Pero cuando suceden, es posible que desee rastrear su causa. Y si es un desarrollador, debe comprender por qué su aplicación falla. Aquí se explica cómo leer los informes de fallas de macOS y clasificar el lenguaje críptico.
Abrir informes de fallas
Cuando una aplicación falla en su Mac, genera automáticamente un informe de bloqueo. Verá que esto aparece después del bloqueo con un cuadro de diálogo de advertencia que dice «[App] se ha ido inesperadamente. Ese informe de bloqueo está disponible para leer inmediatamente en esa ventana haciendo clic en el botón «Informe…». El informe de bloqueo también se puede encontrar en la aplicación Consola.
1. Abra la aplicación Consola escribiendo «Consola» en Spotlight o navegando hasta «Aplicación -> Utilidades -> Consola.aplicación».
2. Haga clic en «Informes de usuario» en el menú de la izquierda, luego haga clic en el informe de bloqueo que desea ver. Todos estos archivos terminarán en «.crash» e incluirán la fecha y la aplicación bloqueada en el título. Los detalles del informe del bloqueo están disponibles en el panel de la derecha.
Lectura de informes de fallos de macOS
Naveguemos por el informe de errores de arriba a abajo.
¿Qué se estrelló?
La primera parte del informe de bloqueo le dice qué «proceso» o aplicación se bloqueó. La parte más importante para el solucionador de problemas promedio es el nombre del proceso.
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
¿Cuándo se estrelló?
La segunda parte nos dice cuándo ocurrió el accidente. También proporciona un poco de información sobre su sistema.
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é causó el accidente?
La siguiente parte es la más esclarecedora. El «tipo de excepción» proporcionado por la aplicación nos dice qué causó el bloqueo. El registro también informa qué subproceso se bloqueó: en este caso, el subproceso 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]
Apple enumera algunos tipos de excepciones comunes en su documentación técnica:
- Mal acceso a la memoria (
EXC_BAD_ACCESS/SIGSEGV/SIGBUS) – el programa intenta acceder a la memoria de forma incorrecta o con una dirección no válida. Se adjunta un código que explica el problema de la memoria. - Salida anormal (
EXC_CRASH/SIGABRT) – salida anómala, por lo general debido a una excepción de C++ no detectada y llamadas aabort() - Trampa de rastreo (
EXC_BREAKPOINT/SIGTRAP) – como SIGABRT, pero esta salida le da al depurador adjunto la oportunidad de interrumpir el proceso en un punto de interrupción y rastrear el error. - instrucción ilegal (
EXC_BAD_INSTRUCTION/SIGILL) – el procesado emitió una instrucción que no se entendió o no se pudo procesar. - Abandonar (
SIGQUIT) – el proceso fue terminado por otro proceso con suficientes privilegios. Por lo general, un proceso de vigilancia finaliza un proceso que se comporta mal. - asesinado (
SIGKILL) – el proceso se terminó a petición del sistema. Se adjuntará un código de terminación para explicar la excepción.
Como podemos ver en nuestro informe de bloqueo, la aplicación intentó acceder a la memoria no asignada. Esto se debe a un error de programación en la aplicación o a un estado de usuario inusual que hace que la aplicación asigne la memoria de forma incorrecta.
¿Qué condujo al accidente?
Después de eso, vemos una lista cronológica inversa de lo que condujo al accidente. Estos están ordenados por subproceso, comenzando con el subproceso 0.
Hay cuatro columnas en este informe. El primero reporta el número del evento en orden cronológico inverso, comenzando en 0. El segundo es el identificador del proceso. El tercero es la dirección del proceso en memoria. El cuarto es el nombre de la tarea del programa.
Este «retroceso» puede ser algo desconcertante. Está «simbolizado», lo que significa que algunas de las direcciones de memoria han sido reemplazadas con nombres de funciones o tareas de aplicaciones. A veces, esto no se puede hacer por completo, dejando direcciones de memoria ilegibles esparcidas por el informe.
Vemos esto en el informe de bloqueo anterior: com.trankynam.aText no está simbolizado. Incluso con una simbolización completa, puede ser difícil leer el rastro inverso. A veces, los desarrolladores incluyen notas útiles sobre tareas y eventos de la aplicación. Otras veces, son títulos crípticos o código numérico. Si puede dar sentido a la simbolización, es posible que pueda comprender lo que está sucediendo. Pero es igualmente posible que necesite haber codificado la aplicación usted mismo para dar sentido a la traza inversa.
Conclusión: ¿Es esto útil?
Si es un desarrollador, leer los informes de fallas es esencial. Le ayuda a comprender qué parte de su aplicación falla y por qué. Si eres un usuario, no son tan útiles. Pero si tiene un bloqueo persistente, los informes de bloqueo pueden ayudarlo a solucionar el problema o trabajar con el desarrollador para solucionar el problema. Es posible que obtenga un código de error útil para Google o que pueda proporcionar soporte técnico con la información correcta. Si quieres conocer los detalles sangrientos, puedes leerlo todo en Nota técnica de Apple sobre bloqueos.