Deciphering iPhone Crash Logs (Symbolication)

Intro

So you’ve submitted your app to the Apple app store and waited a couple of weeks. Then you get an email notifying you that Apple has rejected your app for one reason or another. They attach crash logs retrieved from the device(s) they were testing your app on, but you get them open and you’re left wondering how you could ever decipher anything from the names of frameworks with memory addresses listed.

That’s where symbolication comes in, read on for more.

Looking at the crash logs

Open up the crash log that Apple have sent back (usually attached to the email they send about the reasons for rejection).

Within the error log that is returned from an iPhone, iPad, or iPod device will be the encrypted information about what line of code caused the error to occur in the first place.

We will look at one of the most common errors that occur on iPhone devices in code which is theEXC_BAD_ACCESS (SIGSEGV) which basically means there is an invalid memory reference – seeObjective-C Objects Memory Management Basics for more information about memory allocation in Objective-C.

Looking through the crash log you will see the thread from which the code came from that caused the crash – in the example here, it tells us: Crashed Thread: 6

Scan through the threads in the error log until you find the thread that caused the crash.

The follow are lines of a crash log within this thread;

Thread 6
0 WebCore 0x3029a7c2 0x3023d000 + 382914
1 WebCore 0x3029ac96 0x3023d000 + 384150
17 MyApp 0x00004ee2 0×1000 + 16098

These lines of code are the details from the thread that caused the crash, each item on the left is a framework and on the right is the exact memory address that raised the crash.

In this example the first 2 lines refer to code sections not actually part of the code of the Application – and are from a different framework (in fact part of the iPhone SDK itself). Looking further down the thread execution path, you will notice a reference for your application – in this example: MyApp.

By identifying the memory addresses for your code, you are identifying the lines of code which caused the error to occur.

The memory address for this line is the first code in the 3 that you can see;

 

0x00004ee2 0×1000 + 16098

This is the memory address that refers to the line of code which caused the crash and is what we need to take note of so that we can determine where we need to look to fix the bug. You can do this one of many ways using a variety of tools available to you, but I prefer to use atos (free application with iPhone SDK) as it is extremely easy and quick to use, providing you only with the information you need.

Atos

Atos (Address to Symbol) is a simple tool that translates memory addresses to symbols. All that you require to use this tool is a copy of the exact binary file sent to Apple for submission.

From the memory address you obtained from your crash log, you can point this tool at the binary passing the memory address as a parameter.

The basic use for this tool is as follows:

Syntax: # atos [–o executable] [address ...]

Example: # atos FixMobile 0x00004ee2

(where # symbol is the bash command line)

This will output to the console all the information that atos can determine about the memory address in the executable, for example;

- [MyViewController MyMethod:] (in ProjectName) (MyViewController.m:431)

The information supplied by atos is usually in this format but can depend on the version of the software you are using. The key part of the output is the last line in braces (Class filename : line number).

As soon as you have this information then you can jump straight into your XCode project, into the class and to the line number specified in the output from atos.

Understanding why the line of code crashed can be tricky, but take a logical approach to investigating the bug – test the code in debug under every circumstance that could possibly call that particular line of code. Check what other objects are being used within the line of code because its highly likely that one of the objects is out of scope and already been released from memory when you try to use it

Leave a Reply

You must be logged in to post a comment.