EXC_BAD_ACCESS on device, but fine on Simulator

Question

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 Type: EXC_BAD_ACCESS (SIGBUS)
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

Thanks

Answer 1

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

http://developer.apple.com/iphone/library/documentation/Performance/Conceptual/ManagingMemory/Articles/MallocDebug.html

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

Answer 2

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.

Answer 3

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!