Symbolicating iPhone App Crash Reports

Steps to analyze crash report from apple:

1. Copy the release .app file which was pushed to the appstore, the .dSYM file that was created at the time of release and the crash report receive from APPLE into a FOLDER.

2. OPEN terminal application and go to the folder created above (using cd command)

3. Run atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH. The memory location should be the one at which the app crashed as per the report.

Ex: atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508

This would show you the exact line, method name which resulted in crash.

Ex: [classname functionName:]; -510

Symbolicating IPA

if we use IPA for symbolicating - just rename the extention .ipa with .zip , extract it then we can get a Payload Folder which contain app. In this case we don't need .dSYM file.

Note

This can only work if the app binary does not have symbols stripped. By default release builds stripped the symbols. We can change it in project build settings "Strip Debug Symbols During Copy" to NO.

More details see this post

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.

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)