Demystifying iOS Application Crash Logs

Low Memory Crashes

Since low memory crash logs are slightly different than normal crash logs, this tutorial will address them separately. :]

When a low memory condition is detected on an iOS device, the virtual memory system sends out notifications asking applications to release memory. These notifications are sent to all running applications and processes, in an effort to reduce the total amount of memory in use.

If memory usage remains high, the system may terminate background processes to ease memory pressure. If enough memory can be freed, your application will continue to run and no crash report will be generated. Otherwise, your app will be terminated by iOS, and a low memory report will be generated.

In low memory crash logs, there are no stack traces for the application threads. Instead, the memory usage of each process is reported in terms of the number of memory pages. (At the time of writing, a memory page was 4KB in size.)

You will see jettisoned next to the name of any process terminated by iOS to free up memory. If you see it next to your application’s name, it means the application was terminated for using too much memory.

A low memory crash log looks something like this:

Incident Identifier: 30E46451-53FD-4965-896A-457FC11AD05F
CrashReporter Key:   5a56599d836c4f867f6eec76afee451bf9ae5f31
OS Version:          iPhone OS 3.1.3 (7E18)
Date/Time:           2012-10-17 21:39:06.967 -0400

Free pages:        96
Wired pages:       10558
Purgeable pages:   0
Largest process:   Rage Masters

Processes
         Name                 UUID                    Count resident pages
    Rage Masters <cc527ca9b51937c5adbe035fe27a7b12>    9320 (jettisoned) (active)
    mediaserverd <3d3800d6acfff050e4d0ed91cbe2467e>     255
     dataaccessd <13d80b2e707acc91f9aa3ec4c715b9cc>     505
         syslogd <8eddddc00294d5615afded36ee3f1b62>      71
            apsd <32070d91b216d806973c8f1b1d8077a4>     171
       securityd <b9e51062610d27f727c5119b8f80dcdf>     243
         notifyd <591dd4dd804b4b8741f52335ea1fa4ab>    2027
      CommCenter <b4b87526ae086bb62c982f1078f43f81>     189
     SpringBoard <324939a437d1cca1fa4af72d9f5d0eba>    2158 (active)
      accessoryd <8f21c8b376d16e2ccb95ed6d21d8317a>      91
         configd <85efd41aceac34ccc0019df76623c7a9>     371
       fairplayd <a2eaf736b3e07c7c9a2c82e9eb893555>      93
   mDNSResponder <df1cd275e4ad434e0575990e8e1da4cb>     292
       lockdownd <80d2bd44c0bcca273d48ce52010f7e65>    1204
         launchd <a5988245aade809bf77576f1d9de42c5>      72

When you experience a low memory crash in your app, you should investigate memory usage patterns and how your app responds to low memory warnings. You can use the Allocations and Leaks Instruments to discover memory allocation issues and leaks. If you don’t know how to use Instruments to check for memory issues, you might want to check out this tutorial as a starting point.

And don’t forget virtual memory! The Leaks and Allocations Instruments do not track graphics memory. You need to run your application with the VM Tracker Instrument to see your graphics memory usage.

VM Tracker is disabled by default. To profile your application with VM Tracker, click the Instrument, and check the Automatic Snapshotting flag or press the Snapshot Now button manually.

You will investigate a low memory crash log later on in this tutorial.

Exception Codes

Before you dive into some real-life crash scenarios, there’s one more bit about crash log content that warrants a brief introduction: those funny exception codes.

You can find the exception code in the Exception section of the report – section #3 in the above example. There are a few well-known exception codes that you might encounter often.

Usually, an exception code starts with some text, followed by one or more hexadecimal values, which are processor-specific codes that may give you more information on the nature of the crash. From these codes, you can tell if the application crashed due to a programming error, a bad memory access, or if the application was terminated for some other reason.

Here are some of the more common exception codes:

• 0x8badf00d: Reads as “ate bad food”! (If you squint your eyes and replace the digits with alphabetic characters. :p) This code indicates that an application was terminated by iOS because a watchdog timeout occurred. Basically, the application took too long to launch, terminate, or respond to system events.

• 0xbad22222: This code indicates that a VoIP application was terminated by iOS because it resumed too frequently.
• 0xdead10cc: Read this one as “dead lock”! It indicates that an application was terminated by iOS because it held onto a system resource, like the address book database, while running in the background.
• 0xdeadfa11: Another cute code – read it as “dead fall”! It indicates that an application was force-quit by the user. Per Apple, force quits happen when the user holds down the On/Off button until “slide to power off” appears, then holds down the Home button. As per Apple Documentation, a force quit event results in a 0xdeadfa11 exception code, presumably because the app became unresponsive.

Note: Remember that terminating a suspended app by removing it from the background task list does not generate a crash log. Once an app is suspended, it is eligible for termination by iOS at any time. So no crash log will be generated.

Swimming Time!

All right! You’ve got all the basic background information you need to dive and swim in the pool of crash logs, and fix some nasty bugs! Here is the basic scenario:

You have just started a new job at Rage-O-Rage LLC. The company has a top-selling app in the App Store, Rage Masters.

Your boss, Andy, comes to you and says that to get you started, he has decided to give you a list of different scenarios under which users have claimed the app crashes. Your job is to go through the scenarios and the symbolicated crash logs provided by users, find the bugs in the app, and fix them.

You can download the source code for the app from here.

Note: If you want to regenerate the crash reports for yourself, follow these instructions:

1. Download the code and open the project file in Xcode.
2. Connect an authorized iOS device with the correct provisioning profile.
3. Select the iOS device as the target from the Xcode toolbar – not the Simulator – and build the app.
4. As soon as you see the default screen (the full-screen image of the app) on the device, hit the stop button in Xcode.
5. Close Xcode.
6. Open the app directly on the device.
7. Test the scenarios, and after you are finished, connect the device and get the crash logs via Xcode.