Manually symbolicating iOS crash logs

Today i was approached by our tester who found a crash in an app. It was not reproducible in the latest version but we wanted to find the cause just to be sure. However the app is built by an Xcode bot, so i couldn’t just open the crash log as it wasn’t symbolicated.

Screen Shot 2014-11-28 at 14.39.15

So let’s download the XCArchive from the bot, right? Well, that doesn’t magically symbolise the log as i thought it would. Turns out you have to do some work to get to the honey behind that mysterious 0x100084000 + 530536.

Here is what you have to do

Download the XCArchive, or get find the DSYM file in any way you like. Make sure this is the DSYM file for this particular build that crashed. If you are using Xcode bots you can get this by opening the bot and then the integration.

Screen Shot 2014-11-28 at 14.44.52
Export the .crash report somewhere readily accessible, perhaps the desktop.

Screen Shot 2014-11-28 at 14.47.27

Now you need to find the base load address in your crash. Don’t be alarmed, this is easy. Look at the line of not symbolicated code.

10                       0x0000000100105868 0x100084000 + 530536

What you need is the second group that starts with 0x. In our case it is 0x100084000. Also take note of the “Code Type” parameter in the first lines of the crash. This is the architecture you need to enter in the next command. It’s either armv7 or arm64 nowadays. If it says ARM-64 (Native) you need to enter arm64.

Open a terminal and navigate to the folder with the .crash report and DSYM or XCArchive and run the following command:

xcrun atos -o path/to/DSYM -arch ARCH -l BASE_LOAD_ADDR -f path/to/.crash > path/to/output/.crash

In my case it becomes:

xcrun atos -o ~/Desktop/Archive.xcarchive/dSYMs/ -arch arm64 -l 0x100084000 -f ~/Desktop/crash.crash > ~/Desktop/symbolicated.crash

The result is a symbolicated.crash log, with a lot of extra line breaks. Open this in the text editor of your choice and scroll down to the line that was not symbolicated before. You can search for the memory address right above the unsymbolicated line to find it quickly.

Screen Shot 2014-11-28 at 14.56.59

Now if we search for 0x0000000188c20060, we will find this:

Screen Shot 2014-11-28 at 14.58.16

This tells us that the app crashed at -[HITWebViewController close:] in HITWebViewController.m:99 which is exactly what we were looking for.

Happy bug hunting!




Leave a Reply

Your email address will not be published. Required fields are marked *