Special report: troubleshooting iPhone application crashes

Because of the largely seamless experience, it’s sometimes easy to forget that the iPhone is actually a miniature OS X computer, with real applications that are susceptible to the same unexpected quits and general freezes as their desktop brethren.

The most common iPhone crash is one where the application you are working in suddenly ceases operation, the screen momentarily turns black, then the iPhone home screen appears. In a slightly more serious manifestation, the crash will result in a complete freeze where the iPhone is unresponsive.

Preventing crashes As previously reported, the most crash-prone application on the iPhone is Safari, with Google Maps being a close second. Several readers have reported, and we’ve experienced many times in-house, an issue where Safari suddenly quits when attempting to load Web pages or when scrolling/zooming Web pages.

Crashes are most likely to occur when loading graphics-heavy pages, or those with large (in terms of file size) images. We’ve also noted repeated crashes when using the iPod function in the background then browsing pages with Safari.

There are a few preventative measures for these types of crashes.

• Safari-specific: clear cache, cookies, history Try these options first if you are seeing repeated crashes in Safari. Safari for the iPhone doesn’t have a very aggressive caching mechanism, but sometimes clearing it can trigger stubborn pages to load. Cookies can also become problematic. Delete them and re-try loading the page(s). Finally, deleting History can be effective on the Desktop versions of Safari, and may also be so on the iPhone. All of these items can be cleared by using the Settings application then tapping Safari.
• Full reboot Perform a hard reboot of your iPhone as follows: Turn the iPhone off completely, by pressing and holding the Sleep/Wake button (on top of the device) for a few seconds then slide the red slider. Turn it back on by holding the Sleep/Wake button until the Apple logo appears. This can clear potentially problematic data, preventing some crash-types.
• Keep adequate free space on the iPhone’s internal memory Like its desktop relative Mac OS X, the iPhone’s OS X operating system needs some head-room on the internal flash memory in order to operate properly. Try keeping at least 10% of the total space free to potentially prevent some crashes in applications, freezes and other problems.
• Restore the iPhone Try performing a restore of your iPhone. Connect it to your Mac or PC and, in iTunes, click the Restore button under the Summary tab. Restoring the phone will erase contacts, calendars, photos and other data on the phone, but will restore automatically backed-up information including text messages, notes, call history, contact favorites, sound settings, widget settings, etc.
• Erase all content and settings As a last resort, go to the Settings application, tap General then select the Erase All Content and Settings. This will delete all media and data on the iPhone, as well as recent calls, etc., and all other settings. If you perform this operation and stop experiencing crashes, you might have problematic data being synchronized to the iPhone that is automatically put back when the phone is restored. In this case, you might want to go to iTunes, select Preferences from the File menu, then iPhone and delete your backed up iPhone settings — this includes text messages, notes, call history, contact favorites, sound settings, widget settings. Again, one or more of these data might be problematic.

Finding out what caused crashes Just like Mac OS X, the iPhone generates crash reports when things go wrong. These files are sent back to your computer whenever the iPhone is connected and synchronized with iTunes. In Mac OS X, they’re located in /Library/Logs/Crashreporter/MobileDevice/ under the name of your iPhone.

You might find a variety of files here with different prefixes that end in .crash. For instance, files that start with:

• “Maps” indicate a crash in the Google Maps application
• “MobileSafari” indicate a crash in Safari for iPhone
• “MobilePhone” indicate a crash from the phone application (yes, the phone functionality of the iPhone is an application, and can crash)
• “SpringBoard” indicate a crash from the iPhone application launcher — kind of like the Finder in Mac OS X or Windows Explorer.

You can open these files with any text editor to view their contents. The first section looks like this:

• Process: MobilePhone [30]
• Path: /Applications/MobilePhone.app/MobilePhone
• Version: N/A (N/A)
• Code Type: 0000000C (Native)
• Effective UID: 0
• Parent Process: SpringBoard [15]
• Date/Time: 2007-07-13 17:27:36.372 -0700
• OS Version: OS X 1.0 (1A543a)
• Report Version: 6

Process tells you the name of the application that crashed, and its process number (in brackets). Path tells you where in the iPhone filesystem the application that crashed resides. Parent Process This is usually SpringBoard, the iPhone’s application launcher.

As you can see, you’ll also be presented with information about the version of OS X currently being used by the iPhone, the date and time that the iPhone crash occurred.

Next you’ll see:

• Exception Type: EXC_BAD_ACCESS
• Exception Codes: KERN_PROTECTION_FAILURE at 0×00000005
• Crashed Thread: 0

This tells the user exactly what type of processor exception caused the crash. The above depicted, for instance, “EXC_BAD_ACCESS/KERN_PROTECTION_FAILURE” is caused by the thread trying to write to read-only memory. This is always caused by data access.

Next you’ll see the backtrace, which shows, in reverse chronological order, the series of events that happened right before the crash in each thread, e.g.:

• Thread 0 Crashed:
• 0 libobjc.A.dylib 0×30e980bc 0×30e8a000 + 57532
• 1 Maps 0×00006abc 0×1000 + 23228
• 2 Maps 0×0000745c 0×1000 + 25692
• 3 UIKit 0×3240a9fc 0×323ab000 + 391676

Now you know (in the above example) that the crash occurred while libobjc.A.dylib was being accessed, but before that came the Maps process, and before that the UIKit process. You’ll see files with the dylib suffix often in crash reports. These are OS X dynamic libraries integral to core-level iPhone functions.

RIght now, the best use of iPhone crash logs is seeking of patterns. Look for the most commonly implicated applications and processes, then direct your troubleshooting techniques appropriately. Lots of SpringBoard crashes? Try a reset. Repeated Safari crashes? Clear the cache, cookies and history as aforementioned.

A secondary use is to look for data that might be implicated in the crash, then delete it as mentioned above in the Preventing Crashes section.

Also, remember that you can send these crash reports to Apple when your iPhone is connected, providing the iPhone software team with valuable data that might be rolled into a future update.

Feedback? info@iphoneatlas.com.