Symbolicating iPhone App Crash Reports

Question

I\'m looking to try and symbolicate my iPhone app\'s crash reports.

I retrieved the crash reports from iTunes Connect. I have the application binary that I submitted

Answer 1

For those using Airbrake, there's a solid response above but it wouldn't work for me without tweaking:

Works for some memory addresses but not others, not sure why...

• Create new dir on desktop or wherever
• Find archive in question in Xcode organizer
• Double tap to reveal in finder
• Double tap to show bundle contents
• Copy .dSYM file and .app file into new dir
• cd into new dir
• Run this command: atos -arch armv7 -o 'Vimeo.app'/'Vimeo'
• Terminal will enter an interactive move
• Paste in memory address and hit enter, it will output method name and line number
• Alternatively, enter this command: atos -arch armv7 -o 'Vimeo.app'/'Vimeo' To get info for one address only

Answer 2

Using Xcode 4, the task is even simpler:

• open Organizer,
• click on Library | Device Log in the left column
• click on "Import" button on the bottom of the screen...

and voilà. The log file is imported and Symbolized automatically for you. Provided you Archived the build using Xcode -> Product -> Archive first.

Answer 3

After reading all these answers here in order to symbolicate a crash log (and finally succeeding) I think there are some points missing here that are really important in order to determine why the invocation of symbolicatecrash does not produce a symbolicated output.

There are 3 assets that have to fit together when symbolicating a crash log:

1. The crash log file itself (i.e. example.crash), either exported from XCode's organizer or received from iTunes Connect.
2. The .app package (i.e. example.app) that itself contains the app binary belonging to the crash log. If you have an .ipa package (i.e. example.ipa) then you can extract the .app package by unzipping the .ipa package (i.e. unzip example.ipa). Afterwards the .app package resides in the extracted Payload/ folder.
3. The .dSYM package containing the debug symbols (i.e. example.app.dSYM)

Before starting symbolication you should check if all those artifacts match, which means that the crash log belongs to the binary you have and that the debug symbols are the ones produced during the build of that binary.

Each binary is referred by a UUID that can be seen in the crash log file:

...
Binary Images:
0xe1000 -    0x1f0fff +example armv7  <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
0x2febf000 - 0x2fedffff  dyld armv7s  <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
...

In this extract the crash log belongs to an app binary image named example.app/example with UUID aa5e633efda8346cab92b01320043dc3.

You can check the UUID of the binary package you have with dwarfdump:

dwarfdump --uuid example.app/example
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example

Afterwards you should check if the debug symbols you have also belong to that binary:

dwarfdump --uuid example.app.dSYM
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example

In this example all assets fit together and you should be able to symbolicate your stacktrace.

Proceeding to the symbolicatecrash script:

In Xcode 8.3 you should be able to invoke the script via

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log

If it is not there you may run a find . -name symbolicatecrash in your Xcode.app directory to find it.

As you can see there are no more parameters given. So the script has to find your application binary and debug symbols by running a spotlight search. It searches the debug symbols with a specific index called com_apple_xcode_dsym_uuids. You can do this search yourself:

mdfind 'com_apple_xcode_dsym_uuids = *'

resp.

mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"

The first spotlight invocation gives you all indexed dSYM packages and the second one gives you the .dSYM packages with a specific UUID. If spotlight does not find your .dSYM package then symbolicatecrash will neither. If you do all this stuff e.g. in a subfolder of your ~/Desktop spotlight should be able to find everything.

If symbolicatecrash finds your .dSYM package there should be a line like the following in symbolicate.log:

@dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )

For finding your .app package a spotlight search like the following is invoked by symbolicatecrash:

mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"

If symbolicatecrash finds your .app package there should be the following extract in symbolicate.log:

Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
Found executable <SOME_PATH>/example.app/example
-- MATCH

If all those resources are found by symbolicatecrash it should print out the symbolicated version of your crash log.

If not you can pass in your dSYM and .app files directly.

symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log

Note: The symbolicated backtrace will be output to terminal, not symbolicate.log.

Answer 4

With the latest version of Xcode (3.2.2), you can drag and drop any crash reports into the Device Logs section of the Xcode Organiser and they will automatically by symbolicated for you. I think this works best if you built that version of the App using Build & Archive (also part of Xcode 3.2.2)

Answer 5

I also put dsym, app bundle, and crash log together in the same directory before running symbolicate crash

Then I use this function defined in my .profile to simplify running symbolicatecrash:

function desym
{
    /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more
}

The arguments added there may help you.

You can check to make sure spotlight "sees" your dysm files by running the command:

mdfind 'com_apple_xcode_dsym_uuids = *'

Look for the dsym you have in your directory.

NOTE: As of the latest Xcode, there is no longer a Developer directory. You can find this utility here:

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Vers‌​ions/A/Resources/symbolicatecrash

Answer 6

I found out most of proposed alternatives did not work in latest XCode (tested with Xcode 10). For example, I had no luck drag-dropping .crash logs in Xcode -> Organizer -> Device logs -view.

I recommend using Symbolicator tool https://github.com/agentsim/Symbolicator

• Git clone Symbolicator repository and compile and run with Xcode
• Copy .crash file (ascii file, with stack trace in begging of file) and .xarchive of crashing release to same temporarly folder
• Drag and drop .crash file to Symbolicator icon in Dock
• In 5-30 secs symbolicated crash file is produced in same folder as .crash and .xarchive are