Saltar al contenido

A continuación, le indicamos cómo leer los 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. Cómo leer informes de fallos de macOS y ordenar el lenguaje críptico.

Abrir informes de fallos

Si una aplicación falla en su Mac, generará automáticamente un informe de fallas. Verá esto después del accidente con un cuadro de diálogo de advertencia con la inscripción “[App] Se ha detenido inesperadamente.“Este informe de fallos se puede leer inmediatamente en esta 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 de la consola escribiendo “consola” en Spotlight o navegando a “Aplicación -> Utilidades -> Console.app”.

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 terminan en “.crash” y contienen la fecha y la aplicación bloqueada en el título. Los detalles del informe de fallos están disponibles en el panel derecho.

ConsoleReadCrashReports2

Leer informes de fallos de macOS

Repasemos el informe de fallos de arriba a abajo.

Que se estrelló

ConsoleReadCrashReports3

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ó?

ConsoleReadCrashReports4

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

¿Qué causó el accidente?

ConsoleReadCrashReports5

La siguiente parte es la más reveladora. 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.

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. Adjunto con código que explica el problema de la memoria.
  • Salida anormal (EXC_CRASH / SIGABRT): salida anormal, generalmente causada por una excepción de C ++ no detectada y llamadas abort()
  • Trampa de rastreo (EXC_BREAKPOINT / SIGTRAP) – como SIGABRT, pero esta salida le da al depurador adjunto la opción de interrumpir el proceso en un punto de interrupción y rastrear el error.
  • Instrucción ilegal (EXC_BAD_INSTRUCTION / SIGILL) – el procesador emitió una instrucción que no se entendió o no se pudo procesar.
  • Parada (SIGQUIT) – el proceso fue terminado por otro proceso con derechos suficientes. Un proceso de vigilancia normalmente finaliza un proceso defectuoso.
  • Asesinado (SIGKILL) – el proceso finalizó a petición del sistema. Se adjunta un código de salida para explicar la excepción.
Relacionado : Refrigeración por aire vs. Refrigeración líquida: todo lo que necesita saber

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 está causando que la aplicación asigne memoria incorrectamente.

¿Qué causó el accidente?

ConsoleReadCrashReports6

Después de eso, vemos una lista cronológica inversa de lo que causó el accidente. Estos están ordenados por subproceso, comenzando con el subproceso 0.

Este informe consta de cuatro columnas. El primero da el número del evento en orden cronológico inverso, comenzando con 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 “retroceso” puede resultar un poco confuso. 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 es del todo posible, lo que deja direcciones de memoria ilegibles esparcidas por todo el informe.

Vemos esto en el informe de fallas anterior: com.trankynam.aText no está simbolizado. Incluso con la simbología completa, el retroceso puede ser difícil de leer. A veces, los desarrolladores agregan notas útiles sobre las tareas y los eventos de la aplicación. A veces son títulos crípticos o códigos numéricos. Si puede comprender el simbolismo, posiblemente pueda comprender lo que está sucediendo. Sin embargo, es posible que deba haber codificado la aplicación usted mismo para comprender el backtrace.

Conclusión: ¿eso tiene sentido?

Si es un desarrollador, leer los informes de fallos es fundamental. Le ayudará a comprender qué parte de su aplicación falla y por qué. Si eres un usuario, no son tan útiles. Sin embargo, 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 asistencia técnica con la información correcta. Si desea los detalles sangrientos, puede leerlo todo en la Nota técnica de Apple sobre bloqueos.