Crash logs en iOS

Cmo obtener crash logs?

Dispositivos sincronizados con iTunes

Mac OSX: ~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>
Windows XP: C:\Documents and Settings\<USERNAME>\Application
Data\Apple Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>
Windows Vista o 7: C:\Users\<USERNAME>\AppData\Roaming\Apple
Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>
Xcode
Conectar dispositivo > Windows > Organizer > Devices > Device Logs
iTunes Connect
Sign in to iTunes Connect > Manage Your Applications > click on the app > View
Details > Crash Reports

Cmo se generan estos crash logs?

Violacin de polticas de iOS

Watchdog Timeout: cuando la aplicacin pasa a segundo plano, iOS puede
terminar la aplicacin y generar un crash log si la aplicacin no responde lo
suficientemente rpido al cierre.
El cierre implica la implementacin de los siguientes mtodos:
application:didFinishLaunchingWithOptions:
applicationWillResignActive:
applicationDidEnterBackground:
applicationWillEnterForeground:
applicationDidBecomeActive:
applicationWillTerminate:
El autor sugiere la lectura de los siguientes artculos para ejecutar tareas
largas en segundo plano:
http://www.raywenderlich.com/4295/multithreading-and-grand-cent
ral-dispatch-on-ios-for-beginners-tutorial
http://www.raywenderlich.com/19788/how-to-use-nsoperations-an
d-nsoperationqueues
User Force-Quit: si la app se cuelga, el usuario puede terminarla haciendo
doble tap en el home button; en este caso se genera un crash log.
Excepcin: cuando el usuario tapes el home button para salir de la

aplicacin, esta queda 10 minutos ms o menos funcionando en segundo

plano; luego es terminada automticamente por iOS. Cuando uno borra
una aplicacin pasado ese tiempo, eso no genera un crash log.
Low Memory Termination: una aplicacin que est siendo utilizada tiene toda
la prioridad para usar la memoria que se le asigna; cuando se empieza a quedar
sin memoria, iOS comienza a cerrar las aplicaciones que estn en segundo
plano (no genera crash log para ellas) mientras llama al mtodo
didReceiveMemoryWarning; si al terminar de cerrar las aplicaciones en segundo
plano, la aplicacin an necesita memoria, iOS la termina y genera un crash log.

El mensaje de didReceiveMemoryWarning puede aparecer al poner en memoria

algo muy pesado, aunque sea por un muy corto espacio de tiempo.
El autor sugiere la lectura del siguiente artculo de la documentacin de
Apple: http://developer.apple.com/library/ios/#qa/qa1747/_index.html
Bugs en la aplicacin: causan la mayor cantidad de crashes y, por lo tanto, estn detrs
de la generacin de la mayora de los crash logs.

Analizando un crash log

Process Information
Incident Identifier: un ID del reporte.
CrashReporter Key: el device identifier.
Hardware Model: el tipo de dispositivo.
Process: el nombre de la aplicacin; entre corchetes, el ID del proceso de la
aplicacin al momento del crash.
Basic Information: informacin bsica como fecha, versin de iOS, etc.
Exception: el tipo de excepcin que fue generada al momento del crash, el cdigo de la
excepcin y el thread que la gener.
Threads backtraces: una lista de todos los frames activos durante al momento del crash.
Es una lista de las funciones llamadas cuando crashe. Las 4 columnas significan:
Nmero de frame. Ej.: 0
Nombre del binario. Ej.: libobjc.A.dylib
La direccin de la funcin que fue llamada. Ej.: 0x3c6db5be
La primer parte es la direccin que apunta al archivo y la segunda parte es una
direccin que apunta a la lnea de cdigo de ese archivo. Ej.: objc_msgSend +
30
Thread state: valores de los registros al momento del crash. Usualmente no se utiliza
esta seccin porque la anterior dio toda la informacin necesaria para encontrar el
problema.
Binary images: lista todos los binarios que estaban cargados al momento del crash.

Symbolication

Es el proceso de convertir las direcciones hexadecimales en nombre de mtodos y

nmero de lneas. En el Organizer del Xcode este proceso se realiza automticamente.
Para que Xcode pueda realizar este proceso necesita tener acceso al binario
correspondiente de la aplicacin (el que fue subido al App Store) y al archivo .dSYM que
fue generado durante la compilacin. Tiene que ser exactamente el mismo binario para
que pueda realizarse el proceso de simbolizacin. Por lo tanto, es esencial guardar
cada compilacin distribuida a los usuarios. Se pueden hallar en el Organizer del Xcode,
en Archives.

Crashes por falta de memoria

Los crash logs por falta de memoria son un poco diferentes a los logs comunes. No hay
registro de los threads de la aplicacin. En lugar de eso, reporta el uso de memoria de
cada uno de los procesos tomando como unidad el nmero de pginas de memoria (4
KB).
Para analizar un crash log por falta de memoria, despus de la seccin con la
informacin del proceso y la bsica sigue la siguiente seccin:
Free pages: se refiere a la memoria disponible. Cada pgina tiene
aproximadamente 4 KB.
Purgeable pages: es la memoria que puede ser limpiada y reutilizada.
Largest process: se reefier a la aplicacin que estaba usando la mayor cantidad
de memoria al momento del crash.
Processes: es una lista de procesos junto con su uso de memoria al momento
del crash. Las columnas ofrecen los siguientes datos:
1) Nombre del proceso
2) ID nico del proceso
3) Nmero de pginas que estn siendo utilizadas por el proceso
6) Se ve el estado de cada aplicacin. Usualmente, la aplicacin que
caus el crash es la aplicacin con el estado f rontmost.
En el reporte va a aparecer la palabra j ettisoned al lado del nombre del proceso que fue
terminado por iOS para liberar memoria. Si esa palabra aparece al lado del nombre de
nuestra aplicacin, significa que la aplicacin fue finalizada por usar demasiada
memoria.
Para resolver este tipo de crashes:
Ver cmo responde la aplicacin a las advertencias por falta de memoria.
Usar Instruments: Allocations y Leaks. Se puede empezar con este tutorial
http://www.raywenderlich.com/2696/how-to-debug-memory-leaks-with-xcode-and
-instruments-tutorial y este otro

http://www.raywenderlich.com/23037/how-to-use-instruments-in-xcode
Leaks y Allocations Instruments no controla la memoria virtual que utilizan los
grficos. Usar VM Tracker Instruments para ver el uso de este tipo de memoria y
activar "Automatic Snapshotting" o apretar el botn de "Snapshot Now".

Exception Codes

Hay algunos cdigos que pueden encontrarse con frecuencia y con los cuales puede
deducirse el motivo del crash:
0x8badf00d: "ate bad food". Indica que la aplicacin fue finalizada porque
ocurri un "watchdog timeout", es decir que la aplicacin tard demasiado en
iniciar, terminar o responder a eventos del sistema.
0xbad22222: indica que una aplicacin VoIP fue terminada porque reiniciaba
muchas veces.
0xdead10cc: "dead loco". Indica que la aplicacin fue terminada porque se ubic
en un recurso del sistema mientras se ejecutaba en segundo plano.
0xdeadfa11: "dead fall". Indica sue la aplicacin fue forzada a terminar por el
usuario. Para Apple esto ocurre probablemente cuando la aplicacin no
responde.
SIGABRT: sucede cuando se llama a un mtodo que no existe en un objeto, por
ejemplo cuando se llama indirectamente mediante un selector.