Home/ Questions/Q 94267
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T23:28:29+00:00

When deploying the application to the device, the program will quit after a few

  • 0

When deploying the application to the device, the program will quit after a few cycles with the following error:

Program received signal: 'EXC_BAD_ACCESS'.

The program runs without any issue on the iPhone simulator, it will also debug and run as long as I step through the instructions one at a time. As soon as I let it run again, I will hit the EXC_BAD_ACCESS signal.

In this particular case, it happened to be an error in the accelerometer code. It would not execute within the simulator, which is why it did not throw any errors. However, it would execute once deployed to the device.

Most of the answers to this question deal with the general EXC_BAD_ACCESS error, so I will leave this open as a catch-all for the dreaded Bad Access error.

EXC_BAD_ACCESS is typically thrown as the result of an illegal memory access. You can find more information in the answers below.

Have you encountered the EXC_BAD_ACCESS signal before, and how did you deal with it?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. From your description I suspect the most likely explanation is that you have some error in your memory management. You said you’ve been working on iPhone development for a few weeks, but not whether you are experienced with Objective C in general. If you’ve come from another background it can take a little while before you really internalise the memory management rules – unless you make a big point of it.

    Remember, anything you get from an allocation function (usually the static alloc method, but there are a few others), or a copy method, you own the memory too and must release it when you are done.

    But if you get something back from just about anything else including factory methods (e.g. [NSString stringWithFormat]) then you’ll have an autorelease reference, which means it could be released at some time in the future by other code – so it is vital that if you need to keep it around beyond the immediate function that you retain it. If you don’t, the memory may remain allocated while you are using it, or be released but coincidentally still valid, during your emulator testing, but is more likely to be released and show up as bad access errors when running on the device.

    The best way to track these things down, and a good idea anyway (even if there are no apparent problems) is to run the app in the Instruments tool, especially with the Leaks option.

    • 0