iOS
Depuración se bloquea

Encontrar información sobre un accidente

Cuando su aplicación falla, Xcode ingresará al depurador y le mostrará más información sobre la falla:

Las partes más importantes son:

La flecha roja

La flecha roja muestra qué línea de código se estrelló y por qué se estrelló.

La consola de depuración

Muchos bloqueos registran más información en la consola del depurador. Debería aparecer automáticamente cuando la aplicación falla, pero si no está allí, muestre el depurador seleccionando en la esquina superior derecha de Xcode, y muestre la consola haciendo clic en el botón Botón en la esquina inferior derecha del depurador.

El rastro de pila

El seguimiento de la pila enumera las funciones de las que proviene el programa antes de llegar al código que se bloqueó.

Parte del seguimiento de la pila se muestra en el navegador de depuración a la izquierda de la pantalla, y los controles del depurador le permiten seleccionar un marco de pila para ver en el depurador:

Si ingresa el comando bt en el (lldb) en el depurador y presiona regresar , obtendrá una representación textual del seguimiento de pila que puede copiar y pegar:

(lldb) bt
* thread #1: tid = 0x3aaec5, 0x00007fff91055f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff91055f06 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x000000010008142d libsystem_pthread.dylib`pthread_kill + 90
    frame #2: 0x00007fff96dc76e7 libsystem_c.dylib`abort + 129
    frame #3: 0x00007fff8973bf81 libc++abi.dylib`abort_message + 257
    frame #4: 0x00007fff89761a47 libc++abi.dylib`default_terminate_handler() + 267
    frame #5: 0x00007fff94f636ae libobjc.A.dylib`_objc_terminate() + 103
    frame #6: 0x00007fff8975f19e libc++abi.dylib`std::__terminate(void (*)()) + 8
    frame #7: 0x00007fff8975ec12 libc++abi.dylib`__cxa_throw + 121
    frame #8: 0x00007fff94f6108c libobjc.A.dylib`objc_exception_throw + 318
    frame #9: 0x00007fff8d067372 CoreFoundation`-[__NSPlaceholderArray initWithObjects:count:] + 290
    frame #10: 0x00007fff8d0eaa1f CoreFoundation`+[NSArray arrayWithObject:] + 47
  * frame #11: 0x0000000100001b54 test`main(argc=1, argv=0x00007fff5fbff808) + 68 at main.m:15
    frame #12: 0x00007fff8bea05ad libdyld.dylib`start + 1
    frame #13: 0x00007fff8bea05ad libdyld.dylib`start + 1

La depuración de SIGABRT y EXC_BAD_INSTRUCTION se bloquea

Un SIGABRT o un EXC_BAD_INSTRUCTION por lo general significa que la aplicación se bloqueó intencionalmente porque falló alguna comprobación. Estos deben registrar un mensaje en la consola del depurador con más información; Consulte allí para obtener más información.

Muchos SIGABRT son causados ​​por excepciones Objective-C no detectadas. Hay muchas razones por las que se pueden lanzar excepciones, y siempre registrarán mucha información útil en la consola.

• NSInvalidArgumentException , lo que significa que la aplicación pasó un argumento no válido a un método
• NSRangeException , lo que significa que la aplicación intentó acceder a un índice fuera de los límites de un objeto como una NSArray o una NSString
• NSInternalInconsistencyException significa que un objeto descubrió que estaba en un estado inesperado.
• NSUnknownKeyException generalmente significa que tiene una conexión incorrecta en un XIB. Prueba algunas de las respuestas a esta pregunta .

Depurando EXC_BAD_ACCESS

EXC_BAD_ACCESS significa que el proceso intentó acceder a la memoria de forma no válida, como eliminar la referencia a un puntero NULL o escribir en la memoria de solo lectura. Este es el tipo de bloqueo más difícil de depurar, ya que generalmente no tiene un mensaje de error, y algunos bloqueos pueden ser muy difíciles de reproducir y / o pueden ocurrir en un código completamente ajeno al problema. Este error es muy raro en Swift, pero si ocurre, a menudo puede obtener fallos más fáciles de depurar al reducir las optimizaciones del compilador.

La EXC_BAD_ACCESS errores de EXC_BAD_ACCESS se producen al intentar EXC_BAD_ACCESS referencia de un puntero NULL . Si este es el caso, la dirección que aparece en la flecha roja generalmente será un número hexadecimal que es más bajo que una dirección de memoria normal, a menudo 0x0 . Establezca puntos de interrupción en el depurador o agregue sentencias printf / NSLog ocasionales para descubrir por qué ese puntero es NULL .

Un EXC_BAD_ACCESS que se produce de forma menos confiable o que no tiene ningún sentido podría ser el resultado de un problema de administración de memoria. Los problemas comunes que pueden causar esto son:

• Usando la memoria que ha sido desasignada
• Intentar escribir más allá del final de una matriz C u otro tipo de búfer
• Usando un puntero que no ha sido inicializado

En la sección de Diagnósticos del Editor de Esquemas, Xcode incluye algunas herramientas útiles para ayudar a depurar problemas de memoria:

Address Sanitizer agrega muchos controles que detendrán la aplicación cada vez que surjan problemas de memoria y proporcionarán un mensaje de error útil que detalla exactamente qué sucedió. Zombie Objects detecta problemas con los objetos Objective-C desasignados, pero no debería tener este tipo de problemas con el conteo automático de referencias activado.