Las caídas de aplicaciones en el Mac suelen ser bastante raras. Pero cuando suceden, puede que quieras rastrear su causa. Y si eres un desarrollador, necesitas entender por qué tu aplicación está fallando. He aquí cómo leer los informes de fallos de macOS y clasificarlos en el lenguaje críptico.
Cómo abrir informes de colisión
Cuando una aplicación se bloquea en tu Mac, genera automáticamente un informe de fallo. Verá que esto aparece después de la caída con un cuadro de diálogo de advertencia que dice » [App] ha dejado de funcionar de forma inesperada. » Ese informe de caída está disponible para leerlo inmediatamente en esa ventana haciendo clic en el botón «Reportar…». El informe del accidente también se puede encontrar en la aplicación Consola.
1. Abra la aplicación Consola escribiendo «Console» en Spotlight o navegando a «Application -> Utilities -> Console.app».
2. Haga clic en «Informes de usuario» en el menú de la izquierda y, a continuación, haga clic en el informe de caída que desee ver. Todos estos archivos terminarán en «.crash» e incluirán la fecha y la aplicación estrellada en el título. Los detalles del informe de colisión están disponibles en el panel de la derecha.
Lectura de informes de fallos de macOS
Vamos a navegar por el informe de colisión de arriba a abajo.
¿Qué se estrelló?
La primera parte del informe de caída le dice qué «proceso» o aplicación se ha estrellado. 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 accidente. El registro también informa qué hilo se ha estrellado: en este caso, el hilo 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 excepción comunes en su documentación técnica:
- Mal acceso a la memoria (
EXC_BAD_ACCESS/SIGSEGV/SIGBUS) – el programa intenta acceder a la memoria incorrectamente o con una dirección no válida. Añadido con un código que explica el problema de memoria.
- Salida Anormal (
EXC_CRASH/SIGABRT) – salida anormal, típicamente a la mano de una excepción C++ no capturada y llamadas paraabort()
- Trace Trap (EXC_BREAKPOINT / SIGTRAP) – como SIGABRT, pero esta salida le da al depurador conectado 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 fue entendida o no pudo ser procesada.
- Renuncia (
SIGQUIT) – el proceso fue terminado por otro proceso con suficientes privilegios. Típicamente, un proceso de vigilancia termina con un proceso de mal comportamiento.
- Asesinado (
SIGKILL) – el proceso fue terminado 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 fallo, la aplicación intentó acceder a la memoria no mapeada. Esto se debe a un error de programación en la aplicación o a un estado inusual del usuario que hace que la aplicación mapee la memoria incorrectamente.
¿Qué llevó al choque?
Después de eso vemos una lista cronológica inversa de lo que condujo al accidente. Estos están ordenados por hilo, empezando por el hilo 0.
Hay cuatro columnas en este informe. El primero informa el número del evento en orden cronológico inverso, empezando por 0. El segundo es el identificador del proceso. La tercera 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 por nombres de funciones o tareas de aplicación. A veces esto no se puede hacer completamente, dejando direcciones de memoria ilegibles dispersas por todo el informe.
Vemos esto en el informe del accidente de arriba: com.trankynam.aText no está simbolizado. Incluso con una simbolización completa, puede ser difícil leer el rastro. A veces los desarrolladores incluyen notas útiles sobre las tareas y eventos de la aplicación. Otras veces, son títulos crípticos o código numérico.
Si puedes darle sentido a la simbolización, podrías ser capaz de entender lo que está sucediendo. Pero es igualmente posible que necesites haber codificado la aplicación tú mismo para darle sentido al rastreo.
Conclusión: ¿Esto es útil?
Si usted es un desarrollador, es esencial leer los informes de fallos. Le ayuda a entender qué parte de su aplicación está fallando y por qué. Si usted es un usuario, no son tan útiles. Pero si tiene un fallo persistente, los informes de fallos pueden ayudarle a solucionar el problema o trabajar con el desarrollador para solucionarlo.
Es posible que obtenga un código de error útil para Google o que pueda proporcionar asistencia técnica con la información correcta. Si quieres los detalles sangrientos, puedes leerlo todo en Nota técnica de Apple sobre accidentes
