Symbolicating (mostly) fixed in Xcode 4.1

Posted by on Sep 1, 2011 in Software Development | 15 Comments

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:

/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash

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:

## Warning: Can't find any unstripped binary that matches version of /var/mobile/Applications/98C6D0E7-B85D-4886-AB9F-41DD512CCAD3/SuperCool.app/SuperCool

The easiest way to resolve this is to force Spotlight to index your Archives folder. In a terminal, run this command:

mdimport ~/Library/Developer/Xcode/Archives/

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

  1. Todd Huss
    September 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. :-)

    Reply
  2. Rich
    October 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.

    Reply
  3. Cliff
    October 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.

    Reply
    • Christopher Pickslay
      October 13, 2011

      That’s an interesting one–haven’t come across that. Thanks for sharing it!

      Reply
  4. Pedr
    November 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?

    Reply
  5. Architekt
    December 2, 2011

    I’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.

    Reply
  6. Z S
    December 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.

    Reply
  7. Chris
    January 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…..

    Reply
  8. JPK
    November 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!!

    Reply
    • Christopher Pickslay
      December 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”.

      Reply
  9. JPK
    December 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.

    Reply
    • Christopher Pickslay
      December 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):

      export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer/"
      /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.

      Reply

Leave a Reply