CODEWITHSUNDEEP
iphonexcodegdb
copenndthagen
copenndthagen

Reputation: 50800

What does the following error mean?

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)

Upvotes: 6

Views: 1635

Answers (3)

bbum
bbum

Reputation: 162722

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

Note where the error is; gdb has crashed. This is potentially due to a crash in your application, but that particular messages is certainly not useful to debugging the real problem.

And, more likely than not, the actual crash has nothing to do with an over-release of an object. Maybe so, but likely not.

Typically, when GDB crashes in this fashion, it is because you trashed the heap or stack in a fashion that gdb trips over the corruption trying to figure out what is going on. Or your app has entered a state that gdb can no longer communicate with it (which might be the case here given the crash location).

In this case, some things to try:

  • using latest dev tools? If not, do so and rebuild your app from clean, too.

  • can the crash be reproduced on the simulator and the device? If so, can it be debugged properly on one but not the other?

  • if you run the app without the debugger, can you get it to crash and then extract the crash log from the device?

  • does the behavior change between debug and non-debug builds? That can greatly impact memory corruption.

  • did this just start happening? If so, what did you change most recently?

Thought of another trick;

  • try setting the MallocScribble environment variable. This will scribble values into memory upon allocation/deallocation and can often, at the least, cause a memory corruption related crasher to crash earlier or different enough to catch it.

Upvotes: 23

Jeremy Brooks
Jeremy Brooks

Reputation: 589

To quote a co-worker, "Something went wrong somewhere".

This means that you have attempted to access a pointer that is no longer valid. Perhaps you forgot to retain an object, or released it one too many times?

Upvotes: 0

jakeva
jakeva

Reputation: 2835

EXC_BAD_ACCESS usually means you are trying to access something that doesn't exist anymore. We'd need your stack dump and probably some code to help you figure it out.

Upvotes: 1

Related Questions