Technical Note TN2151

Understanding and Analyzing iPhone OS Application Crash Reports

This document contains essential information for developers who wish to receive and process crash reports for their iPhone OS applications.

Report Types Symbolication Acquiring Crash Reports The Xcode Organizer Document Revision History

Report Types

There are four distinct kinds of crash reports. They are:

• Application crash: possibly the most common kind of report, this is generated when execution is halted due to bad memory access, an exception or some other programming error.

• Low memory: occurs when the application has been killed by the system because there wasn't enough memory to satisfy the application's demands. The format of this report differs from the others in that there are no stack traces for the application threads. Rather than be concerned about what part of your code was executing at the time of termination, you should investigate your memory usage patterns and your responses to low memory warnings. Memory usage of each process is reported in terms of number of memory pages, which as of this writing are 4KB each.

• User force-quit: distinguished by exception code 0xdeadfa11. Force quits occur when the user holds down the home button for six seconds. It's reasonable to assume the user has done this because the application has become unresponsive, but it's not guaranteed - force-quit will work on any application.

• Watchdog timeout: distinguished by exception code 0x8badf00d. Timeouts occur when an application takes too long to launch, terminate, or respond to system events.

Except for the low memory crash logs, these logs contain stack traces for each thread at the time of termination. The next section discusses those traces.

Back to Top

Symbolication

The most interesting part of a crash report is the stack trace of your application at the time execution halted. This trace is similar to what you would see when stopping execution in the debugger, except that you are not given the method or function names, known as symbols. Instead, you have hexadecimal addresses and executable code - your application or system frameworks - to which they refer. You need to map these addresses to symbols. Unlike crash logs from Mac OS X, iPhone OS logs do not contain symbol information when they're written out. You have to symbolicate iPhone OS logs before you can analyze them.

Symbolication - resolving stack trace addresses to source code methods and lines - requires the application binary that was uploaded to the App Store and the .dSYM file that was generated when that binary was built. This must be an exact match - otherwise, the report cannot be fully symbolicated. It is essential that you keep each build distributed to users (regardless of the details of that distribution) with its .dSYM file. See The Xcode Organizer for information on how Xcode can help you manage this.

Given a crash report, the matching binary, and its .dSYM file, symbolication is easy. The Xcode Organizer window has a section specifically for Device Logs, and dragging a crash report to this window will symbolicate the crash report and display the results.

Back to Top

Acquiring Crash Reports

When an application crashes on the iPhone or iPod touch, a "crash report" is stored on the device. Crash reports describe the conditions under which the application terminated, in most cases including a complete stack trace for each executing thread, and are typically very useful for debugging issues in the application.

When the user synchronizes their device using iTunes, crash reports are copied to a directory on the user's computer. If the application was distributed via the App Store and the user has chosen to submit crash logs to Apple, the crash log will be uploaded and the developer can download it via iTunes Connect. For applications that have been distributed using Ad Hoc or Enterprise methods, getting crash reports requires user cooperation. Specifically, the user will need to retrieve the crash report from the directory where it was copied by iTunes. Depending on the platform, the directory is:

• Mac OS X: ~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>

• Windows XP: C:\Documents and Settings\<USERNAME>\Application Data\Apple Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>

• Windows Vista or 7: C:\Users\<USERNAME>\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\<DEVICE_NAME>

<USERNAME> is the user's login name for the computer. <DEVICE_NAME> is the name of the iPod touch or iPhone, for example, "John's iPhone".

You are only interested in .crash files. The crash report's file name begins with the application name and contains date/time information. In addition, <DEVICE_NAME> will appear at the end of the file name, before the extension.

Back to Top

The Xcode Organizer

The Xcode Organizer allows you to easily manage many development needs related to iPhone OS development, and managing crash reports is no exception. By default the Xcode Organizer will display and symbolicate all crash reports that it finds either on devices or already downloaded by iTunes. These crash reports are available organized by device or as a whole. To see crash reports by device, select that device and then select the Device Logs tab. To see all crash reports that Xcode has obtained, select the Device Logs entry under iPhone Development. To add crash reports to the listing, drag them into the listing.

Xcode will automatically symbolicate all crash reports that it encounters, but in order to do so it must have the .dSYM and application binary that produced the crash report.

Xcode 3.2.2 introduces the "Build and Archive" command to aid in this process. When you use the Build and Archive command, Xcode will gather the application binary and the .dSYM containing symbol information together and store them in a location in your home folder. You can find all of your archived applications in the Xcode Organizer under the Archived Applications section. Xcode will automatically search archived applications when symbolicating crash reports, and you can submit archived applications directly to iTunes Connect ensuring that the application and .dSYM that you have archived match what you release.

Back to Top

Document Revision History