Cómo leer informes de fallos de macOS para solucionar problemas de su Mac

Las fallas de aplicaciones en Mac son generalmente bastante raras. Pero cuando suceden, es posible que desee rastrear su causa. Y si es un desarrollador, debe comprender por qué falla su aplicación. A continuación, le mostramos cómo leer los informes de fallos de macOS y ordenar el lenguaje críptico.

Abrir informes de fallos

cómo-leer-informes-de-fallos-1

Cuando una aplicación falla en su Mac, genera automáticamente un informe de fallas. Verá que esto aparece después del bloqueo con un cuadro de diálogo de advertencia que dice “[App] ha salido inesperadamente.”Ese informe de fallos está disponible para leerlo inmediatamente en esa ventana haciendo clic en el botón“ Informar … ”. El informe de fallos también se puede encontrar en la aplicación de consola.

1. Abra la aplicación Consola escribiendo “Consola” en Spotlight o navegando a “Aplicación -> Utilidades -> Console.app”.

cómo-leer-informes-de-fallos-2

2. Haga clic en “Informes de usuario” en el menú de la izquierda, luego haga clic en el informe de fallas 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 de fallos están disponibles en el panel de la derecha.

consola-lectura-informes-de-fallos-2

Leer informes de fallos de macOS

Naveguemos por el informe de fallos de arriba a abajo.

¿Qué se estrelló?

consola-lectura-informes-de-fallos-3

La primera parte del informe de fallos le indica qué “proceso” o aplicación falló. La parte más importante para el solucionador de problemas promedio es el nombre del proceso.

¿Cuándo se estrelló?

consola-lectura-informes-de-fallos-4

La segunda parte nos dice cuándo ocurrió el accidente. También proporciona un poco de información sobre su sistema.

¿Qué causó el accidente?

consola-lectura-informes-de-fallos-5

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 falló: en este caso, subproceso 0.

Apple enumera algunos tipos de excepciones comunes en su documentación técnica:

  • Acceso incorrecto 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 anormal, normalmente a causa de una excepción de C ++ no detectada y llamadas a abort()
  • 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.
  • Dejar (SIGQUIT): El proceso fue terminado por otro proceso con suficientes privilegios. Por lo general, un proceso de vigilancia finaliza un proceso de mal comportamiento.
  • Asesinado (SIGKILL): El proceso finalizó 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 fallos, la aplicación intentó acceder a la memoria no asignada. Esto se debe a un error de programación en la aplicación o un estado de usuario inusual que hace que la aplicación asigne la memoria de forma incorrecta.

¿Qué provocó el accidente?

consola-lectura-informes-de-fallos-6

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 informa 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 la memoria. El cuarto es el nombre de la tarea del programa.

Este “rastreo” puede resultar algo desconcertante. Está “simbolizado”, lo que significa que algunas de las direcciones de memoria se han reemplazado 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 fallas anterior: 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 eventos y tareas de la aplicación. Otras veces, son títulos crípticos o códigos numéricos. Si puede entender la simbolización, es posible que pueda comprender lo que está sucediendo. Pero es igualmente posible que tenga que haber codificado la aplicación usted mismo para entender el backtrace.

Conclusión: ¿Es esto útil?

Si eres un desarrollador, leer los informes de fallos es fundamental. 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 una falla persistente, los informes de fallas 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 pueda proporcionar al soporte técnico la información correcta. Si quieres los detalles sangrientos, puedes leerlo todo en Nota técnica de Apple sobre accidentes.

¿Es útil este artículo?

¡Compártelo en tus redes!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *