Xcode no pasará por alto el choque

Entonces, esto ha sucedido varias veces en varios proyectos diferentes. Depuraré mi aplicación en Xcode, cuando Xcode rompa un error. Después de mirarlo, golpeaba Paso a paso o Continuar … y no haría nada. Más exactamente, actuó como si caminara, pero en realidad no fue a ninguna parte. Esto puede repetirse indefinidamente, por lo que puedo decir. Una razón por la que esto es problemático es que nunca me da el logging de locking, porque nunca termina de estrellarse. Solo recibo el logging de locking cuando la aplicación falla y no está siendo depurada (lo que significa que tengo que hacerlo a través de Crittercism o revisando los loggings del dispositivo).

¿Alguien lo ve antes y / o sabe por qué lo hace? No he visto ninguna mención de esto en otros lugares, pero me ha sucedido en varios proyectos.

Por ejemplo, en un proyecto utilizamos SocketRocket, y de vez en cuando (por razones aún desconocidas) se cuelga en SRWebSocket.m en el siguiente método:

- (void)main; { @autoreleasepool { _runLoop = [NSRunLoop currentRunLoop]; dispatch_group_leave(_waitGroup); NSTimer *timer = [[NSTimer alloc] initWithFireDate:[NSDate distantFuture] interval:0.0 target:nil selector:nil userInfo:nil repeats:NO]; [_runLoop addTimer:timer forMode:NSDefaultRunLoopMode]; int i = 0; while ([_runLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]]) { NSLog(@"_runLoop %i %@", i++, [NSDate date]); } assert(NO); } } 

Se cuelga en la línea while . (Agregué la línea NSLog, por cierto). Cuando presiono Continuar o Pasar, el indicador de línea parpadea brevemente, luego aparece de nuevo en la misma línea. Tenga en count que no continúa con la línea NSLog, y nada se escribe en la console. Todavía estoy intentando que se bloquee nuevamente (este locking en particular es bastante impnetworkingecible), pero si no recuerdo EXC_BAD_ACCESS , el indicador de línea dice EXC_BAD_ACCESS , probablemente un object prematuramente desasignado.

Un error ObjC fuera de range resultará en lanzar una exception ObjC, que termina, si no se ha capturado, en un aborto. Un aborto realmente solo eleva una señal BSD (SIGKILL). Es fácil que el depurador pase al process para que pueda morir de forma natural a partir de él.

EXC_BAD_ACCESS y EXC_BAD_INSTRUCTION son divertidas excepciones, ya que primero entran en el lado Mach del sistema operativo. Para que se propaguen correctamente, deben manejarse de forma nativa como excepciones de Mach si hay un controller para ellos y, de lo contrario, deben pasarse a algún controller de sistema, que los convierte en la exception BSD equivalente (SIGSEGV) que luego se pasará a el manejador de señal BSD y que eventualmente hará que su progtwig salga.

Hay un error de larga data en las interfaces del núcleo ofrecido al depurador que hace que sea imposible para el depurador efectuar correctamente este pequeño baile desde el exterior. Entonces, si obtienes un EXC_BAD_ACCESS, estás bastante atrapado allí. En su mayor parte, eso no importa mucho, su progtwig solo iba a dar la vuelta y morir de todos modos. Realmente no obtendría ninguna idea de su crash al verlo hacer eso.

Solo importa si ha instalado y desea depurar un controller SIGSEGV. Eso ha sido difícil para MacOS X durante una década o más. Afortunadamente, solo unas pocas personas realmente necesitan hacer esto …

Te estás perdiendo el punto de paso. Cuando camina sobre una línea, está diciendo que ejecuta la línea actual e ir al siguiente visible, independientemente de si la línea actual llama a otro procedimiento.

Si el código falla en cualquier momento, no podrá continuar ejecutando líneas de código.

Para agregar a las respuestas anteriores; cuando se depura y EXC_BAD_ACCESS, a veces puede ayudar a "Habilitar objects zombis" en su esquema. Si está accediendo a un object que ha sido desasignado, los objects zombies le dirán a qué object no debería haber intentado hacer una llamada y el método al que intentó llamar.