iPhone Crash with “No Backtrace”

Question

My iPhone app was recently rejected from the App Store \"because it crashes on launch\". However, I cannot reproduce this crash. The app works perfectly on both the simulato

Answer 1

See Technical Note TN2151:Understanding and Analyzing iPhone OS Application Crash Reports. Symbolication would normally help you track down the source of a crash but since there is no backtrace it may not help in this instance.

Don't bother testing on the simulator. The simulator build and the device build are wholly separate compiles for two different pieces of hardware. Just because it runs on simulator tells you nothing about a failure on device.

Remember that Apple will stress test the app by doing things like launching it on iOS4 with other apps eating up most of the memory. You will need to do that as well on your test device.

You will most likely have to wipe your test device back to defaults to replicate the test Apple does. Then open every possible app before launching your own.

Answer 2

A segfault is unlikely to be a build error. To reproduce this problem, try clearing out any saved information on the iPhone simulator before running the project; it is possible that you are assuming the existence of certain entries in NSUserDefaults that are present on your own iPhone, but which would not be available on a default installation. If that doesn't reproduce the problem, then you should create unit tests for each of your components, ruling out each component at a time as the cause of failure. Eventually, you will have ruled out every cause of failure except for the true cause of failure.

Answer 3

I was never able to reproduce the crash. I messed with a few build params and resubmitted and it was approved.

Answer 4

You can make some information from the ARM thread state. The PC register is the only one containing the invalid address that the crash report is complaining about. That means your app tried to execute code at that address.

SIGSEGV means that the address in question is invalid. The system has setup no memory pages with this address.

I don't think the iOS will allow you to simply execute code from any address, but it is possible that the stack frame was corrupted and the return address was invalid when a function returned. That supports the "backtrace not available" problem.

Fouling the stack may be a result of a buffer overrun. If you use memcpy or a loop of sets on a local variable array and overrun the end of the array, you can destroy the stack.