Program received signal: “EXC_BAD_ACCESS”.
[Switching to process 388]
kill
error while killing target (killing anyway): warning: error on line 2179 of "/SourceCache/gdb/gdb-1472/src/gdb/macosx/macosx-nat-inferior.c" in function "macosx_kill_inferior_safe": (os/kern) failure (0x5x)
quit
The Debugger has exited with status 0.(gdb)
Señal de programa recibido: "EXC_BAD_ACCESS". [Cambiando a proceso 388] kill error while killing target (matando de todos modos): advertencia: error en la línea 2179 de "/SourceCache/gdb/gdb-1472/src/gdb/macosx/macosx-nat-inferior.c " en función "macosx_kill_inferior_safe": (OS/Kern) fracaso (0x5x) dejar de fumar
Nota dónde está el error; gdb se ha estrellado. Esto se debe potencialmente a un bloqueo en su aplicación, pero esos mensajes particulares ciertamente no son útiles para depurar el problema real.
Y, muy probablemente, la falla real tiene nada que ver con un exceso de lanzamiento de un objeto. Tal vez sea así, pero probablemente no.
Normalmente, cuando GDB se cuelga de esta manera, es porque destruyó el montón o la pila de manera que gdb tropieza con la corrupción tratando de descubrir qué está pasando. O bien, su aplicación ha entrado en un estado en el que gdb ya no puede comunicarse (lo que podría ser el caso aquí dada la ubicación del bloqueo).
En este caso, algunas cosas para probar:
utilizando las últimas herramientas dev? Si no, hágalo y reconstruya su aplicación de limpia, también.
¿Se puede reproducir el bloqueo en el simulador y el dispositivo? Si es así, ¿se puede depurar correctamente en uno pero no en el otro?
si ejecuta la aplicación sin el depurador, ¿puede hacer que se bloquee y luego extraer el registro de bloqueo del dispositivo?
¿cambia el comportamiento entre compilaciones de depuración y no de depuración? Eso puede tener un gran impacto en la corrupción de la memoria.
¿esto comenzó a suceder? Si es así, ¿qué cambiaste más recientemente?
Pensamiento de otro truco;
MallocScribble. Esto garabateará los valores en la memoria al asignar/desasignar y, a menudo, al menos puede provocar que un bloqueador relacionado con la corrupción se bloquee antes o sea lo suficientemente diferente como para atraparlo.¡seguro que adoran tu respuesta! – jakev
Terminé votando el resto de las respuestas ... no estaban * bien * pero tampoco eran punibles. Este es uno de esos ** bichos duros **. Si hubieras estado haciendo un desarrollo directo como recién llegado y te encontraras en una situación como esta, la suposición de un exceso de lanzamiento sería fácil y natural ... y completamente desconcertante mientras tratas de descubrir qué demonios está pasando en realidad. . – bbum
+1 para @ bbum, principalmente causa debido al lanzamiento temprano o posterior ...... – Sabby
EXC_BAD_ACCESS generalmente significa que está tratando de acceder a algo que ya no existe. Necesitaríamos su volcado de pila y probablemente algún código para ayudarlo a resolverlo.
¿cómo lo consigo? – testndtv
EXC_BAD_ACCESS solo significa que a veces; a veces significa que tropezó con la memoria corrupta. Y, en este caso, es la falla del depurador lo que significa que el bloqueo en la aplicación original probablemente no sea el típico problema de retención/liberación. – bbum
¿por qué se bloquearía el depurador, qué podría salir mal que no se origina de un error en el código de la operación? – jakev
Para citar a un compañero de trabajo, "Algo salió mal en alguna parte".
Esto significa que ha intentado acceder a un puntero que ya no es válido. ¿Quizás olvidó retener un objeto o lo liberó demasiadas veces?
No, esta secuencia significa que ** gdb ** se colgó. La aplicación probablemente se colgó primero y ese fue el desencadenante, pero nada de lo que se publica da pistas sobre exactamente qué salió mal. Que el depurador se cuelgue probablemente signifique que la aplicación corrompió la memoria por encima y más allá de una simple liberación excesiva. – bbum
¡Gracias por la aclaración! –
Definitivamente una pregunta muy real; He visto casos como este donde se trata de la totalidad de la pista dada. Una dificil. – bbum