This post contains essential information for developers who wish to receive and process crash reports for their iPhone OS applications.
3.Acquiring Crash Reports
4.The Xcode Organizer
There are four distinct kinds of crash reports. They are:
i)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.
ii)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.
iii)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.
iv)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.
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.
IMPORTANT: You must keep both the application binary and the .dSYM file in order to be able to fully symbolicate crash reports. You should archive these files for every build that you submit to iTunes Connect. The .dSYM and application binary are specifically tied together on a per-build-basis, and subsequent builds, even from the same source files, will not interoperate with files from other builds. If you use the Build and Archive command as discussed in The Xcode Organizer then they will be placed in a suitable location automatically. Otherwise any location searchable by Spotlight (such as your home directory) is fine.
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.
3.Acquiring Crash Reports
iTunesConnect service — a web site that iPhone developers use to manage their published applications — has a separate area that will list all the synced crash reports from the application users.
However, not all of the crashes appear there, or are slow to appear. Thus, if you have a desperate problem with someone’s application, it’s a good idea to pick these up and send them to a developer.
Here’s how, in three major operations systems: Mac OS X, Windows Vista / Windows 7 and for Windows XP.
Application crash logs are transferred to your computer each time you do a sync with the device, in the iTunes. Thus, first step is to sync with iTunes:
Sync the iPhone or iPod Touch through iTunes
Mac OS X
On the Mac, crash logs are kept at:
where ~ is your Home folder. Here’s an example:
Crash logs on the Mac OS X. Device name is “iPhone AV” here
There’s the .crash file and .plist file – archive them both and send to a developer. Actually, pick all the files you find there that have the name of the problematic application.
Windows Vista / Windows 7
Files are located here:
AppData folder is hidden by default, so here’s how to access it. Get into your personal folder:
User folder, with Vista folder path
Now click on the folder (address) bar which will change the display into Windows folder path and add \AppData to it, then click Enter.
When clicked, the address bar changes into regular Windows folder path
This will then show the folder contents. From here, you can follow the path above until you get to the crash logs.
For Windows 7, follow the same procedure.
Location is here:
C:\Documents and Settings\<USERNAME>\Application Data\Apple computer\Logs\CrashReporter/<DEVICE_NAME>
<USERNAME> is your login username. Application Data folder is usually hidden by default, so you need to reveal it in the same way as in Vista — by typing in and pressing Enter.
4.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.