Force symbolicatecrash to use a specific .app and .dSYM file?

Question

I have a .crash log from an ad-hoc version of my app that symbolicatecrash refuses to symbolicate. I have already applied the .patch to remove the 'die' command in symbolicatecrash after apple broke the script in XCode 3.2.6. Symbolicatecrash has worked for other crash logs but refuses to symbolicate this one. My ad hoc app was built and is stored in "Archived Applications", so there is no reason why XCode shouldn't be able to find it. I have even copied the .app and .dSYM files right next to the .crash log, no dice.

Is there a way I can force symobolicatecrash to use a specific .app and .dsym files even if it doesn't think it applies?

Answer 1

OK turns out this answer is now what is required for the latest XCode 5.1.1:

Recently I had a crash log from an ad-hoc build. XCode refused to Symbolicate. I had an archived build a few hours old and I wanted to force a symbolication using my archived build. Here is how I did it:

1) First I opened a terminal window and went to the directory containing my archive. I ran this command:

xcrun dwarfdump --uuid Example.app/Example | tr '[:upper:]' '[:lower:]' | tr -d '-'

This pulled out the dsym_uuid of the archived build. The tr command converts the guid from an uppercase guid with dashes to a lowercase guid with no dashes

2) I went into the .crash file and changed the guid associated with my binary in the crash log to the guid associated with the xcdarchive on my machine

For example, went from

   0x80000 -   0x49efff +MyApp armv7  <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa> /var/mobile/Applications/DC23BDC0-75E3-4DCA-8AC3-099889CE22E0/MyApp.app/MyApp

to

   0x80000 -   0x49efff +MyApp armv7  <bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb> /var/mobile/Applications/DC23BDC0-75E3-4DCA-8AC3-099889CE22E0/MyApp.app/MyApp

3) From the terminal, I set my DEVELOPER_DIR environment var to:

export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer

4) Finally, I ran this beast of a command:

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash -v MyApp.crash /Users/me/Library/Developer/Xcode/Archives/2013-05-31/MyApp\ 5-31-13\ 7.00\ PM.xcarchive/Products/Applications/MyApp.app

Note that the path to symbolicatecrash changes in newer versions of XCode, to:

 /Applications/Xcode6.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

This command run symbolicatecrash against your archive using the .crash file you have

Answer 2

Turns out I accidentally deleted the build associated with the crash log. symbolicatecrash uses the following logic to figure out if there are symbols associated with a crash log:

At the bottom of every crash log is a list of Binary Images. Yours is listed first. There is a guid associated with your binary image. For example:

0x1000 -   0x2befff +MyApp armv7  <a95274a309d73458a40cb5a6fd317a1c> /var/mobile/Applications/91884634-DA1A-4BDB-9E1E-6F487D8F25D7/MyApp.app/MyApp

The relevant guid is: a95274a309d73458a40cb5a6fd317a1c

It next uses the tool mdfind, which looks at metadata associated with files in your file system, for the uppercase and hyphenated form of that GUID.

From your archived applications, if you click on MyApp.app.dSYM, then Get Info, then disclose More Info, you will see dSYM UUIDs and two GUIDs listed. The second GUID is the one that is relevant. It will be of the form:

A95274A3-09D7-3458-A40C-B5A6FD317A1C

Provided that the second GUID matches the guid in the .crash file, symbolicate crash will be able to find and symbolicate. If they don't match, it's the wrong binary.

Cheers, Eric

Answer 3

A little additional information which may help.

I have two UUIDs listed, and my first one matches the one in the crash log, not the second. However my crash comes from a device running ARM6, whereas the OPs came from one running ARM7

I therefore deduce that each UUID matches an architecture, if you build for ARM6 and ARM7 and the crash comes from a device running ARM6, then you'll need to match the first UUID, if it is running ARM7 you'll need the second.

If you only have one UUID, I think you probably only built for one architecture.

This is mainly deduction, but seems likely.

Answer 4

There is a new process for extracting build UUIDs described here:

https://developer.apple.com/library/ios/qa/qa1765/_index.html

This is now the magical command to run to extract build UUID:

xcrun dwarfdump --uuid Example.app/Example | tr '[:upper:]' '[:lower:]' | tr -d '-'

Answer 5

I have been able to force symbolicatecrash to symbolicate my crash log by overriding the dSYM UUID to the expected crashlog's UUID.

Put dsym and unsymbolicated.crash in same folder.

Run ./symbolicatecrash in Verbose mode:

./symbolicatecrash unsymbolicated.crash > symbolicated.crash -d ./MyApp.app.dSYM/ -v 

Scroll to bottom and find the crashlog's expected UUID:

Did not find dsym for db3e90fa8b6d462c9d65049ab1f22ea4
-- [db3e90fa8b6d462c9d65049ab1f22ea4] NO MATCH (spotlight)

In Finder right click your .dsym file and click "Get Info" under "More Info" section header you will have the dSYM UUIDs: property. Copy this value to clipboard.

Using a hex editor (I used iHex from App Store) open MyApp.dysm/Contents/Resources/DWARF/MyApp and CMD+F the copied UUID.

Replace this UUID with the expected expected one in this example I replaced it with: "db3e90fa8b6d462c9d65049ab1f22ea4".

NOTE: While this is exceptionally hacky and does not guarantee success and will more then likely result in mis-symbolicated crash with nonsensical method names but maybe it will work for you!