¿Registros de bloqueos generados por iPhone Simulator?

96

¿Hay registros de fallos generados por iPhone Simulator?

el simulador se bloquea mucho pero no deja ningún rastro en la consola ... el registro de fallas será útil.

iphone ios-simulator crash-reports

— Raptor
fuente

2

No entiendo muy bien por qué necesita los registros de fallos. Cuando la aplicación en el simulador falla, pero antes de detener la depuración, en el indicador de gdb escriba "bt" para "backtrace"; obtendrá exactamente lo que aparecería en el registro de fallas. (no me di cuenta de que había preguntas sobre nigromancia aquí, se perdió el año posterior)

— Matthew Frederick

3

Si el bloqueo solo se produjo cuando el depurador no lo adjuntó, entonces necesitaría los registros.

— Ian1971

tienes razón. esto tiene sentido!

— Raptor

También puede ver el registro de depuración (incluida la salida de los comandos lldb) en el "Navegador de informes" en Xcode (cmd-8). Esto también es útil para ver la salida de depuración de ejecuciones anteriores. Si el depurador no estaba adjunto, obviamente esto no funcionará.

— Sebastien Martin

2

El registro de depuración no es lo mismo que el registro de bloqueos, aunque ambos registros son útiles para depurar el problema.

— Raptor

157

La consola mostrará el NSLog()resultado de una aplicación que se ejecuta en el simulador. Los registros de fallos se guardan en un archivo.

He encontrado algunos en mi directorio personal bajo

~/Library/Logs/DiagnosticReports/

Tienen una extensión de archivo de .crash

Algo que aún no he descubierto es cómo hacer que se generen incluso si el depurador captura la EXC_BAD_ACCESSseñal.

Actualizar

Actualmente, (OSX 10.11.6), el .crash inicia sesión ~/Library/Logs/DiagnosticReports, es cuando el propio emulador falla . Los registros de una aplicación que falla (pero el dispositivo emulador aún funciona bien) se encuentran en:

~ / Biblioteca / Registros / CoreSimulator

Por falla, hay una subcarpeta con una identificación única. Ordene por fecha, de modo que su bloqueo reciente sea la primera subcarpeta. Dentro de eso, comience mirando stderr.logy system.log.

También directamente debajo CoreSimulator, ver CoreSimulator.logy Simulator.log.

— ohhorob
fuente

¿Alguna idea de por qué estos registros se escriben en un archivo en lugar de aparecer en la consola? Por cierto, gracias por la información.

— aqua

11

Ninguno de mis informes de fallas en el simulador de iPhone o iPad aparece en este directorio, ¿tal vez esta respuesta deba actualizarse?

— Justin

3

Quizás necesite una actualización, pero un voto negativo no es una forma muy educada de fomentarlo.

— ohhorob

2

Encontré el informe de fallas en el directorio mencionado, pero solo había un informe y no era el más reciente (es decir, seguí probando algunas cosas en la aplicación y seguía fallando). Las fallas fueron todas iguales, por lo que no fue un problema, pero me pregunto si este es generalmente el caso.

— Samik R

10

Tanto Justin como ohhorob tienen razón. Debe iniciar la aplicación en el simulador SIN Xcode y reproducir el bloqueo para ver los registros~/Library/Logs/DiagnosticReports/

— Dave Chambers

20

Estoy bastante seguro de que puede ver esto en la aplicación OS X Console ubicada en Utilidades. Sin embargo, si me equivoco, asegúrese de votarme en contra para que elimine esto.

ACTUALIZAR:

Específicamente (a partir de OSX 10.11.6),

Cuando una aplicación falla en el emulador, se agrega una subcarpeta (con una identificación única) a:

~ / Biblioteca / Registros / CoreSimulator

Dentro de eso, comience examinando stderr.logy system.log.

Cuando el emulador en sí se bloquea, se añade a una subcarpeta:

~ / Library / Logs / DiagnosticReports

No confundas este camino con

/ Biblioteca / Registros

(falta ~al inicio), que tiene diferentes informes sobre su mac.

— bpapa
fuente

Sí. Más información aquí developer.apple.com/iphone/library/documentation/Xcode/…

— Brandon Bodnar

Parece que solo se aplica a dispositivos iPhone, en lugar de simulador. Corrígeme si estoy equivocado.

— Raptor

7

La consola se puede abrir desde el simulador presionando Cmd- / o usando la opción de menú Debug / Open System Log ...

— lambmj

5

Aquí hay algo que funcionó para mí en un caso especial ... Mi aplicación se bloqueó con SIGKILL cuando terminó. Vería la excepción en main.m durante unos segundos, y luego la aplicación terminaría de terminar, por lo tanto, no habría posibilidad de obtener el seguimiento.

Hice muchas búsquedas sobre "dónde el simulador almacena sus registros de fallos" y nunca logré encontrar una respuesta. Sin embargo, el siguiente truco fue bastante útil y pude agarrar el registro de fallas sobre la marcha:

Básicamente, abra /Applications/Utilities/CrashReporterPrefs.app y cambie la configuración a "Desarrollador". Esto hará que CrashReporter muestre una ventana emergente con el registro de fallas después de que su aplicación se bloquee.

Encontré esto en la sección "Visualización de la consola del simulador de iOS y los registros de fallos" en este documento de Apple: http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/ios_development_workflow/125-Using_iOS_Simulator/ios_simulator_application. html

— dana_a
fuente

Por cierto, el problema original con SIGKILL que estaba investigando resultó no ser un problema: stackoverflow.com/questions/7901262/…

— dana_a

Debo señalar que no había ninguna aplicación CrashReporterPrefs en Aplicación / Utilidades, sin embargo, la busqué y pude encontrar la aplicación en otro lugar.

— Justin

@Justin ¿dónde lo encontraste?

— Ohad Schneider

1

Tenga en cuenta que la herramienta mencionada anteriormente se puede descargar de Xcode en un paquete llamado "Herramientas adicionales para Xcode" developer.apple.com/download/more/…

— markshiz

1

Esto es mucho más confiable. En solo unos pocos pasos pude encontrar el número de línea de origen y el nombre del método:

cd al directorio que tiene los archivos .app y .dSYM
ejecutar /Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin MyApp.app/MyApp
activar la impresión asm-demangle
establecer imprimir símbolo-nombre de archivo en
p / a 0 × 00015c64 -> dirección obtenida abriendo el registro de fallas en la aplicación "Consola" o simplemente haciendo doble clic en el archivo .crash.

— Punto gamma
fuente

3

No entiendo muy bien por qué necesita los registros de fallos. Cuando la aplicación en el simulador falla, pero antes de detener la depuración, en el indicador de gdb escriba "bt" para "backtrace"; obtendrá exactamente lo que aparecería en el registro de fallas.

— Matthew Frederick

Este método funciona muy bien para los registros de fallos de los teléfonos de los clientes.

— Gamma-Point

1

Los registros de fallos aparecerán en ~ / Library / Logs / CrashReporter.

Si el programa del simulador de iPhone falla (no la aplicación de iPhone que se ejecuta dentro del simulador), habrá una entrada para iPhoneSimulator.
Si la aplicación de iPhone dentro del simulador falla, el registro de fallas aparecerá con el nombre para mostrar de la aplicación.

Cuando Xcode obtiene registros de bloqueo de un dispositivo conectado, los almacena en subcarpetas de ~ / Library / Logs / CrashReporter / MobileDevice

— Vendedores de Walt
fuente

Esto es más de un año después, pero veo que la "aplicación dentro del simulador" se bloquea en ~ / Library / Logs / DiagnosticReports ... y se ve así: MobileSafari_2013-03-21-155844_My-MacBook-Pro.crash

— Rob

0

Para mí, era una expresión que había agregado a la ventana de observación del depurador. Cuando se alcanzaba un punto de interrupción, la expresión incorrecta provocaba que XCode fallara en el segmento.

— pTymN
fuente