Por lo general, las aplicaciones que fallan en una Mac son muy raras. Pero cuando eso sucede, es posible que desee realizar un seguimiento de estos problemas. Y si es un desarrollador, debe comprender por qué su aplicación falla. Aquí se explica cómo leer y ordenar los informes de fallas de macOS por idioma codificado.
Abrir informes de fallos
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 "[La aplicación] se detuvo inesperadamente". Este informe de bloqueo está disponible para lectura inmediata en esta 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 vaya a "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 terminan con ".crash" e incluyen la fecha y la aplicación rota en el título. Los detalles del informe del bloqueo están disponibles en el panel de la derecha.
Leer informes de fallas de Mac OS
Repasemos el informe del fallo de arriba a abajo.
¿Qué es lo que choca?
La primera parte del informe de fallos le mostrará si un proceso o aplicación lo "bloquea". La parte más importante para un solucionador de problemas 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 fueron las vacaciones?
La segunda parte nos dice cuándo ocurrió la falla. 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 mal funcionamiento?
La siguiente parte es la más esclarecedora. El 'Tipo de excepción' que ofrece la aplicación nos dice qué causó el mal funcionamiento. El registro también informa qué subproceso se ha bloqueado: 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]
listas de manzanas Algunos tipos comunes de excepciones En su documentación técnica:
Acceso deficiente a la memoria (EXC_BAD_ACCESS / SIGSEGV / SIGBUS): el programa intenta acceder a la memoria incorrectamente o con una dirección no válida. Con un código que explica el problema de la memoria.
Salida anormal (EXC_CRASH / SIGABRT): salida anormal, generalmente de la mano de una excepción no suspendida de C ++ y una llamada a abort ()
Trace Trap (EXC_BREAKPOINT / SIGTRAP): igual que SIGABRT, pero esta terminación le da al depurador adjunto la oportunidad de interrumpir el proceso en un punto de interrupción y rastrear el error.
Instrucciones ilegales (EXC_BAD_INSTRUCTION / SIGILL) – El procesamiento emitió un procesamiento que no se entendió o no se pudo procesar.
Salir (SIGQUIT): el proceso fue terminado por otro proceso con suficientes privilegios. Por lo general, el proceso de seguimiento finaliza el proceso de mala praxis.
Terminar (SIGKILL) - El proceso ha sido terminado a petición del sistema. Se agregará un código de salida para explicar la excepción.
Como podemos ver en el informe de bloqueo, la aplicación intentó acceder a la memoria que no está en cuarentena. Esto se debe a un error de programación en la aplicación oa una condición inusual del usuario que hace que la aplicación asigne memoria incorrectamente.
¿Qué conduce al mal funcionamiento?
A continuación, vemos una lista cronológica inversa de lo que desencadena el bloqueo. Estos están ordenados por subproceso, comenzando con el subproceso 0.
Hay cuatro columnas en este informe. El primero informa el número de evento en orden cronológico inverso, comenzando con 0. El segundo es el ID del proceso. El tercero es la dirección del proceso en memoria. El cuarto es el nombre de la tarea del programa.
Este "deshacer" puede ser algo desconcertante. Son "simbólicos", lo que significa que algunas direcciones de memoria han sido reemplazadas por nombres de funciones o tareas de aplicaciones. A veces, esto no se puede hacer por completo, dejando direcciones de memoria ilegibles llenas de informes.
Vemos esto en el informe de bloqueo anterior: com.trankynam.aText no es un token. Incluso con la codificación completa, el fondo puede ser difícil de leer. Los desarrolladores de software a veces incluyen notas útiles sobre las tareas y los eventos de la aplicación. Otras veces, son direcciones encriptadas o un código numérico. Si puede comprender el simbolismo, es posible que pueda comprender lo que está sucediendo. Pero en la medida de lo posible, deberá codificar la aplicación usted mismo para comprender el seguimiento inverso.
Conclusión: ¿Es esto útil?
Si es un desarrollador de software, es fundamental que lea los informes de fallos. Esto lo ayuda a comprender qué parte de su aplicación está causando problemas y por qué. Si eres un usuario, no son útiles. Pero si tiene un bloqueo constante, los informes de bloqueo pueden ayudarlo a solucionar el problema o trabajar con el desarrollador para solucionar el problema. Puede obtener el código de error resuelto de manera útil a través de Google o puede enviarlo al soporte técnico con la información correcta. Si desea detalles drásticos, puede leer todo al respecto en Nota técnica de Apple sobre bloqueos.
