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 simulator and a device with the same hardware and software Apple tested it on (iPhone 3.1 running iOS 4). The crash logs they sent me say "No Backtrace Available", so I have nowhere to look in my code. Here's an example:

Incident Identifier: [...]
CrashReporter Key:   [...]
Hardware Model:      iPhone3,1
Process:         [MyApp] [1172]
Path:            /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp]
Identifier:      [MyApp]
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2010-07-08 [...]
OS Version:      iPhone OS 4.0 (8A293)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xfe42c648
Highlighted Thread:  0

Backtrace not available

Unknown thread crashed with ARM Thread State:
    r0: 0x00002388    r1: 0x00000000      r2: 0x3e2b47c8      r3: 0x00000108
    r4: 0x2fe00000    r5: 0x00000000      r6: 0x00000000      r7: 0x00000000
    r8: 0x2ffffb48    r9: 0x2fffecfc     r10: 0x00000000     r11: 0x00000000
    ip: 0x00000010    sp: 0x2ffffb4c      lr: 0x2fe08907      pc: 0xfe42c648
  cpsr: 0x40000010

Binary Images:
    0x1000 -    0x78fff +[MyApp] armv7  <23af3d265c3086eaceb51cc649eb794f> /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp]
0x2fe00000 - 0x2fe26fff  dyld armv7  <697ae459733a7f0b6c439b21ba62b110> /usr/lib/dyld
[many more libraries...]

How can I begin debugging this? Is it possible this is a build issue rather than a coding bug? And can I extract any useful information from the "ARM Thread State" or the "Binary Images" portions of the crash report?

Thanks!

*update: * I have installed the app for the first time on another iPhone running iOS 4 and still cannot reproduce the crash. I'm beginning to think this is an issue with build-time parameters such as libraries or targeted versions. Based on the crash report, is it likely that any of my application's code was executed?

Triceps

Answer 1

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

Triceps

Answer 2

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.

Elidaelidad

Answer 3

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.

Briquet

Answer 4

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.

Larhondalari

Good idea; I tried resetting the simulator but had no luck. And the code that runs on startup is trivial, but I'll triple-check it anyways. – Triceps

Testing needs to be done on a device. Not being able to reproduce a crash in the simulator is meaningless. – Seen