Symbolicating (mostly) fixed in Xcode 4.1
I previously posted why Xcode 4’s symbolication is broken, along with a patched script that fixes it. As of Xcode 4.1, Apple has fixed the problems in the symbolicatecrash script, though I’ve found that it still often does not symbolicate correctly. Here are the most common problems (and solutions) I’ve come across:
Xcode is using the wrong symbolicatecrash script.
Before Xcode 4.1, sybmolicatecrash was installed in /usr/local/bin/symbolicatecrash. As of Xcode 4.1, it’s moved to a private framework in the iPhone SDK:
Xcode generally seems to pick up the right version, but some people have reported that it still uses the old version in /usr/local/bin. If you’re not using an older version of Xcode, you can safely delete the one in /usr/local/bin.
The archive isn’t in Spotlight’s index
If you’re using the right symbolicatecrash script and it still doesn’t resolve symbols in your app, it’s likely that Spotlight hasn’t indexed your archive. You can verify this by running symbolicatecrash against the crash report manually with the -v flag. Near the top of the output, you’ll see something like:
The easiest way to resolve this is to force Spotlight to index your Archives folder. In a terminal, run this command:
Once this completes, you should be able to symbolicate again. You can do that either by running symbolicatecrash on the command-line, or you can force Xcode to re-symbolicate the crash log. First delete the logs it’s already symbolicated, which should be in
~/Library/Logs/CrashReporter/MobileDevice/<your device name>.symbolicated. Then get Xcode to re-scan for un-symbolicated logs, which you can usually do by connecting a device.
Todd HussSeptember 1, 2011
I think I know why that guy is so frustrated! It’s because he’s trying to symbolicate the iOS crash log on a Dell Windows laptop. 🙂
RichOctober 12, 2011
Thanks for this info! Really appreciate it!
One item I found is that I still needed to get spotlight to find the archives directory with my install of Xcode 4.2 and had to use the following command:
mdimport -g /XCode\ -\ ios5/Applications/Xcode.app/Contents/Library/Spotlight/SourceCode.mdimporter ~/Library/Developer/Xcode/Archives/
Since I did not install Xcode for iOS 5 over the top of my main developer directory I had to tell mdimport which plugin to use and where to locate the plugin to search source directories.
Christopher PickslayOctober 13, 2011
Good catch, Rich. Thanks for the note!
CliffOctober 13, 2011
Thanks for the post! In my case, mdimport was failing. The reason turned out to be a 1K file at Library/Spotlight/iWeb.mdimporter. Once I removed that file, I was able to run the mdimport ~/Library/Developer/Xcode/Archives/ command without errors, and my app’s dSYM file could be located properly. Then Xcode 4 started symbolicating my crash reports properly.
Christopher PickslayOctober 13, 2011
That’s an interesting one–haven’t come across that. Thanks for sharing it!
PedrNovember 30, 2011
Thanks for this. I don’t suppose you have any idea why symbolication would be working fine for my own classes, but failing for all framework classes?
Christopher PickslayNovember 30, 2011
It sounds like the symbolicatecrash script isn’t finding your SDK. Try running it from the command line with the -v flag and take a look at the output.
Christopher PickslayDecember 1, 2011
Pedr, it looks like this is a known issue with Xcode 4.2 and iOS 5.0.1: https://devforums.apple.com/message/580062#580062
ArchitektDecember 2, 2011
I’m not doing archives (yet), so for me what fixed the problem was I additionally had to do this:
Once I did that, magically everything worked.
Z SDecember 15, 2011
This worked for me in the past, but it’s not symbolicating anymore. When I do a filename search for .xcarchive with a Spotlight search (or even MyApp.app.dSYM), it doesn’t return any results, even after running the mdimport command. Any ideas? I’ve tried everything others have mentioned above, but no luck. So frustrating.
ChrisJanuary 11, 2012
Wow…thank you so much. I was going mad trying to figure out why I couldn’t symbolicate archived crash logs. Now just need to find the bug…..
JPKNovember 30, 2012
I submitted my app the the App Store under a name with a space and an apostle (along the line of “Angie’s List”). I now have crash reports from users and I have been trying for days to no avail to get the crash files symbolicated for the methods in my app. I can get the UIKit, Core data, etc. methods symbolicated, but the methods from my own are are not, no matter what I do. Any help would be GREATLY appreciated. Thanks!!
Christopher PickslayDecember 3, 2012
I doubt the problem has anything to do with the name of your app. If it’s symbolicating, but not resolving the methods in your code, it’s almost certainly because it can’t find the archive you submitted to the app store. Are you trying to symbolicate on the same machine you built the archive from? Is the archive you submitted there in the Xcode Organizer? It should have a status of “Submitted”.
JPKDecember 4, 2012
No. It’s the app name. Try to create a sample app with the name “Jacob’s Ladder” and see what happens. I have the app file, the dsym, spotlighted, in same folder as crash logs, uuids match, everything. Try the sample project and let me know what you find. Use an apostrophe and a space in your app name.
Christopher PickslayDecember 4, 2012
It’s definitely not the spaces. I imagine there might be a quoting bug in the symbolicatecrash script. If you run it by hand with the -v flag you may be able to see what the problem is. Then you’ll have to dig into the script to patch it. I advise making a copy of the script before you start modifying it. Here’s how to run it by hand (assuming Xcode is installed in /Applications):
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -v <path-to-your-crash-report>
Near the top of the output, it searches for the dsyms it needs to look up the symbols. Look for “Did not find executable for dsym”. You may have to add some logging to the getSymbolPathFor_dsymUuid method in the symbolicatecrash script to uncover exactly where the bug is.