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.
15 Comments
Todd Huss
September 1, 2011I 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. 🙂
Rich
October 12, 2011Thanks 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 Pickslay
October 13, 2011Good catch, Rich. Thanks for the note!
Cliff
October 13, 2011Thanks 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 Pickslay
October 13, 2011That’s an interesting one–haven’t come across that. Thanks for sharing it!
Pedr
November 30, 2011Thanks 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 Pickslay
November 30, 2011It 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 Pickslay
December 1, 2011Pedr, it looks like this is a known issue with Xcode 4.2 and iOS 5.0.1: https://devforums.apple.com/message/580062#580062
Architekt
December 2, 2011I’m not doing archives (yet), so for me what fixed the problem was I additionally had to do this:
mdimport ~/Library/Developer/Xcode/DerivedData
Once I did that, magically everything worked.
Z S
December 15, 2011This 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.
Chris
January 11, 2012Wow…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…..
JPK
November 30, 2012I 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 Pickslay
December 3, 2012I 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”.
JPK
December 4, 2012No. 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 Pickslay
December 4, 2012It’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.