Processing user's crash logs (when symbolicate don't work)

Writing software is not a science. It is hard and very error prone. As an iOS developer you may already know that when an application crashes on the iPhone, a crash log is generated. Syncing your device to iTunes will sync those logs and send them to Apple. Then, as a developer you go on iTunes connect once in a while to see what, if any, crash logs a awaiting for you.

Often, you'll have to hit Refresh in order to have an up to date view of accumulated crash logs. 

Then, you'll discover that there is no crash log report. Two reasons for this: your application is perfect and never crashed or, and this is the most likely reason, users don't sync their device often enough so you don't get the crash logs. This is for this exact reason that I decided to include a crash reporter in the latest release of Ultimate Password Manager. I don't like to wait for users to sync their devices. Since the updated has been approved by Apple, I receive 2-3 crash reports per day. This may seems bad but in reality, this is cool because now I have something to work on and see what going on!

Here is a crash log receive by mail.

Then next step is to symbolicate this with the symbolicatecrash command line. The result look like this.

The crash log shows the call stack at the moment the application crashed. What I see is the UIKit call stack with symbolicated addresses. But for my application, I don't get the actual symbols. As you can see on the web, search for "symbolicate not working", I'm not the only one with this problem. There is a very simple solution to this.

First, keep the archived package from Xcode Organizer when you submit an application to the App Store. In Xcode Organizer, select the desired archive and hit Reveal in the Finder. Next, right-click on the file and select Show Package Content. Copy all two items from this folder (the actual .app file, the dSYM file). Next, copy one of the received crash log. Then, in Terminal, follow these steps:

1. cd
2. enter: atos -o applicationName.app/applicationName

The address that is important to look is found in the call stack. In my example, this is number 3. I want to know, what line of code and method name this correspond to. So the address I enter is 0x00008547. The result is very simple but so much more telling:

-[uPasswordsAppDelegate saveDataEncrypted] (in uPasswords) (uPasswordsAppDelegate.m:1269)

The problem is located in the application delegate method called: saveDataEncryted at line 1269. The next step is to open the source project for this release and go to this line of code to get the content of the problem. That it. 

Hope this help. More on this subject here: Deciphering iPhone Crash Logs (Symbolication). Happy debugging.