Take the 2-minute tour ×

I have a scroll view app which runs fine on the simulator, however, when installed on the device, it gives me an EXC_BAD_ACCESS, when i attempt to scroll one page. I have ran it through Instruments with Allocations and Leaks, but nothing is leaked and no zombies are messaged... i'm just curious what could cause such a difference in simulator vs device? Any ways to debug this, since my symbolicated crash log (partial below), doesn't seem to be very symbolicated.

Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000f
Crashed Thread: 0

Thread 0 Crashed:
0 libobjc.A.dylib            0x0000286e objc_msgSend + 18
1 MyApp                       0x00004fee 0x1000 + 16366
2 UIKit                         0x000668f4 -[UIViewController view] + 104
3 MyApp                     0x00009716 0x1000 + 34582
4 MyApp                     0x0000960c 0x1000 + 34316
5 UIKit                         0x0001426c -[UIScrollView setContentOffset:] + 344


share|improve this question
are you accessing some data/media stored/downloaded in your app's documents directory (i.e. something on device but not a part of the bundle..) cause the code to access it behaved differently for simulator and device sometimes... (i don't remember how i solved it though.. or if i was doing something wrong..) –  lukya Aug 27 '10 at 11:43
I do have a few images but they are all in resources and so should get copied over to the device. Thats the only thing i can think of. –  joec Aug 27 '10 at 12:06
Please check, if they really get copied to the bundle. If so, you will find them here: "Groups & Files" Browser -> "Targets" -> Your Target -> "Copy Bundle Recourses". If not, just add it there. –  vikingosegundo Aug 27 '10 at 13:30
yeah they are all in the copy bundle resources phase. –  joec Aug 27 '10 at 13:46
add comment

3 Answers

up vote 2 down vote accepted

Your code in the simulator could have the bug, but isn't triggering EXC_BAD_ACCESS by just the luck that a pointer that you dereference is not in unmapped memory. A pointer could be bad, and accessed, but not detected -- it's still a bug.

You have already checked to see that no Zombies are messaged, which would have been my first suggestion.

The next thing to do is Enable Guard Malloc -- and then read this


You can only do this in the simulator -- your goal is to use the extra-sensitive heap to make the bug throw EXC_BAD_ACCESS in the simulator.

In the article:

  1. Look at how to set the variables in GDB
  2. Read the "Detecting Heap Corruption" section
share|improve this answer
add comment

Bad access on the device can be caused for lots of reasons, most of them related to the fact the device has less memory than the simulator, therefore it would dealloc released memory sooner.

The best way it find the problem is running the app on the device in debug mode without breakpoints (one why of doing it is to add breakpoint and then remove it). If you can reproduce the bad access that way, after reproducing it, you can look ay the debugger console (cmd+shift+y) and you'll see that the program has stopped at a breakpoint alike place, then go on the thread stack to see the last call your app did and failed, probably accessing a bad pointer.

share|improve this answer
thanks buddy, i found my problem using your way of finding variable under memory problem....Thanks –  Kamal Sharma Jul 9 '13 at 6:26
add comment

I would like to add my case to the discussion. I just solved a problem really similar to this one. It worked on the Simulator but failed on device. Thought it was a memory issue. It was not.

Turns out I had forgotten the return on a non-void method. It was expected to return a value but I forgot to make the return altogether. Pretty bad error if you ask me, but it ran without a problem in Simulator (even when the return was actually being used to store the variable and do some other stuff with it).

Somehow the Simulator worked every time with the return forgotten. Beats me how, but I can only wildly guess it has to be placing the last variable I use in the same place the return should be pointing to, resulting in a false (false but correct) return.

Then ran on device and under normal conditions it crashed every single time. Took me a step by step debug to realize I was not properly returning the result of the failing method.

Hope it helps anyone facing this issue!

share|improve this answer
add comment

Your Answer


