Romper en EXC MAL ACCESO en XCode?

Acerca de su matriz. La línea

NSMutableArray *array = [NSMutableArray array];

En realidad no le da un objeto retenido sino más bien un objeto de autorelease. Probablemente se mantiene en la siguiente línea, pero entonces no debe liberarlo en la tercera línea. Ver esto

Esta es la regla fundamental:

Usted toma posesión de un objeto si lo crea utilizando un método cuyo nombre comienza con "alloc" o " new " o contiene "copy" (por ejemplo, alloc, newObject o mutableCopy), o si le envía un mensaje de retención. Usted es responsable de renunciar a la propiedad de los objetos que posee utilizando release o autorelease. En cualquier otro momento que reciba un objeto, no debe liberarlo.

En Xcode 4, puede habilitar Zombies haciendo clic en el menú desplegable Scheme (arriba a la izquierda, a la derecha junto al botón stop) -> Editar Scheme -> Pestaña Diagnostics -> Habilitar Objetos Zombie

Xcode/gdb siempre se rompe en EXC_BAD_ACCESS, solo necesita trabajar su camino hacia arriba en la pila de llamadas para encontrar el código que lo activó.

Tenga en cuenta que este tipo de errores a menudo ocurren con objetos autoreleased, lo que significa que la causa última del problema no estará en la pila de llamadas que activó EXC_BAD_ACCESS. Es entonces cuando NSZombieEnabled y NSAutoreleaseFreedObjectCheckEnabled se vuelven útiles.

Una nueva respuesta a un hilo antiguo... en XCode 4 la forma más efectiva de diagnosticar excepciones EXC_BAD_ACCESS es usar Instrumentos para perfilar su aplicación (desde XCode haga clic en Producto/Perfil y elija Zombies). Esto le ayudará a identificar los mensajes enviados a objetos desasignados.

De las clases de Stanford CS193P: si agrega un punto de interrupción (manualmente, editando puntos de interrupción) para el símboloobjc_exception_throw puede obtener una imagen mucho mejor de lo que salió mal: dejar que las cosas procedan al punto donde el depurador se detiene por sí mismo tiende a oscurecer las cosas y arruinar el seguimiento de la pila. Cuando se detiene en objc_exception_throw, a menudo puede mirar hacia atrás exactamente qué acceso / operación causó su problema.

Otro enfoque útil es establecer puntos de interrupción que se activarán directamente después de que ocurra la excepción:

Abra la ventana de puntos de interrupción (Run-Show-Breakpoints) y agregue dos puntos de interrupción simbólicos llamados "objc_exception_throw" y "[NSException raise] "

Desde: http://blog.emmerinc.be/index.php/2009/03/19/break-on-exception-in-xcode/

Solo quería agregar para los demás que vienen de una web, buscando soluciones para el mismo error pero con error diferente. En mi caso obtuve el mismo error cuando traté de instanciar NSDictionary con error tipográfico en el nombre de la clave donde olvidé agregar " @ " delante de mi clave:

NSDictionary *dic = [NSDictionary dictionaryWithObjectsAndKeys: myObj1, @"goodKey", myObj2, "badkey @ is missing in front", nil];

Espero no haberme perdido una respuesta idéntica, pero he encontrado que es posible que algunos proyectos arrojen este error debido a que se ejecutan en simuladores para versiones anteriores de iOS que pueden ser incompatibles con una dependencia o marco de trabajo del proyecto. Estuve persiguiendo uno de estos durante demasiado tiempo antes de darme cuenta de que estaba sucediendo en las versiones de simuladores más antiguos, como el iPhone 4S, la aplicación ni siquiera se suponía que intentara soportar.

Habría sido bueno haber recibido un mensaje de error más detallado, pero me imagino que esa es la responsabilidad del marco donde se originó... En cualquier caso, este es un aterrizaje de búsqueda bastante común y tal vez esto ayudará a alguien haciendo el tonto tan mal como me encontré a mí mismo.

Antes de habilitar zombies, recomiendo primero deshacerse de todas las advertencias (si tiene alguna). Cosas simples como una función no void sin returnpueden causar este error. Si no tiene advertencias, proceda como sugieren las otras respuestas.