Can’t symbolicate XCode4 archive builds?

Posted by on Apr 6, 2011 in code | 11 Comments

Update: symbolication is fixed in Xcode 4.1. Check this post for troubleshooting tips if you’re still having problems.

Since XCode 4 was released, several iOS developers have reported that their crash reports are no longer symbolicated correctly, meaning that they can’t trace crashes to the code that caused them. I’ve traced this problem down to the Perl script that XCode uses to map the addresses in a crash report to their symbols, symbolicatecrash. I’ve patched the script to get it working, which you can download here. This is not beautiful Perl (if there is such a thing), and it makes some assumptions about how files are nested, so YMMV. But it works for me.

Archiving in XCode 4

Organizer - ArchivesIt’s been possible to archive a build in XCode for a while, primarily to preserve it in a place you could get to from the Organizer. In XCode 4, the archive process has been streamlined, and it’s the best way to create ad hoc builds for distributing to beta testers, and release builds to submit to the app store. Once you create an archive, you can click the Share… button in the Organizer to create an .ipa file for ad hoc distribution (I use HockeyKit for this, and many people like TestFlight, though I find their admin UI confusing). You can also click the Submit… button to re-sign the same build for app store distribution and submit to iTunes Connect, so you know you’re submitting the exact same code you’ve been testing on the device.

The Problem

In XCode 3.x, Build and Archive created an .ipa file. XCode 4 introduces a new format, the .xcarchive directory, which is what leads to the symbolication problem. The symbolicatecrash script uses Spotlight to locate both the .dSYM file with the symbols, and the actual binary. In XCode 3, Spotlight would return the directories where these files could be located, and symbolicatecrash would find them. However, with .xcarchives, Spotlight returns the .xcarchive directory, and the files symbolicatecrash needs are nested a few levels within that directory. Since symbolicatecrash expects them to be directly in one of the directories returned by Spotlight, it fails to look any further, and fails to resolve the symbols.

The Fix

First symbolicatecrash does a Spotlight search for the .dSYM directory for the UUID of the app from the crash log:

mdfind "com_apple_xcode_dsym_uuids == 2E0EB467-3372-3235-A692-40754870C921"


It expects this to return the .dSYM directory, but for XCode 4 archive builds, it returns the .xcarchive directory. If the result doesn’t match the pattern .*.dSYM, my edited version globs 2 directories deeper until it finds it.

Next symbolicatecrash does a Spotlight search for the actual executable name:

mdfind SuperCool.app


It then checks each result with otool for a UUID matching the crash log. Again Spotlight returns .xcarchive directories for all the builds archived using XCode 4, even though the actual executable is nested a few folders deeper, inside Products/Applications. My edited version of the script again globs deeper for the executable if the Spotlight result is an .xcarchive directory.

What’s Next?

For now, the patched script works fine, so feel free to move /usr/local/bin/sybmolicatecrash aside and copy in the edited version. You can run it manually against a crash log with the -v flag to see all the dirty details. Please don’t comment on how crappy my Perl edits are, but please feel free to fork my repo and improve on it. I’ve filed this as rdar://problem/9241304

11 Comments

  1. MarcS
    May 3, 2011

    Please file it also at
    http://openradar.appspot.com/

    Reply
  2. adam
    June 2, 2011

    Um … under OS X 10.6.7 there *is* no “/usr/local/bin”, let alone an existing symbolicatecrash binary in there?

    Reply
    • Christopher Pickslay
      June 2, 2011

      Try running “locate symbolicatecrash” in a terminal. In my case, there’s now one in /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash.

      It appears that XCode 4.0.2 is now using that version, not the one in /usr/local/bin. In my case, the one under the /Developer path seems to have fixed the .xcarchive problem, though it still pukes on simulator builds. You can fix that by changing line 323 from:

      die “Can’t understand the output from otool ($TEST_uuid -> ‘$otool -arch $arch -l $path’)”;

      to:

      print STDERR “Can’t understand the output from otool ($TEST_uuid -> ‘$otool -arch $arch -l $path’)\n” if $opt{v};

      Reply
  3. Bart Jacobs
    June 15, 2011

    The updated version of symbolicatecrash works very well. Instead of dropping it in /usr/local/bin though, I replaced Xcode 4’s version of symbolicatecrash and Xcode now automatically symbolicates crash reports like it used to.

    Thanks very much, Christopher!

    Reply
  4. mobdim
    June 27, 2011

    Not work for me ((

    Reply
  5. Junjie
    July 2, 2011

    Thanks Chris, I haven’t been able to symbolicate anything since Xcode 4. Now I can!

    Reply
  6. Semmel
    August 3, 2011

    Works like a charm! Thank you for doing the work for Apple!
    It’s a pity I can not flattr you.
    (XCode 4.0.2, Mac OS 10.6.8)

    Reply
  7. Ramon Gonzalez
    August 22, 2011

    Worked great. Thanks!
    (XCode 4.0.2, Mac OS 10.6.8)

    Reply
  8. ghr
    October 1, 2011

    Hi,
    I get the following messages. The warning at line 268 occurs a very large number of time. My App “App Name” is not symbolicated (libraries are). My app has a space in its name.
    usr/local/bin/symbolicatevcrash did not exist.

    symbolicatecrash *.crash “App Name 26-09-11 2.15 PM.xcarchive”
    Use of uninitialized value $executable in substitution (s///) at /usr/local/bin/symbolicatecrash line 233.
    Use of uninitialized value $executable in substitution (s///) at /usr/local/bin/symbolicatecrash line 237.
    Use of uninitialized value $executable in scalar chomp at /usr/local/bin/symbolicatecrash line 238.
    Use of uninitialized value $pathToDsym in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 239.
    Use of uninitialized value $dsymBaseName in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 239.
    Use of uninitialized value $executable in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 239.
    Use of uninitialized value $executable in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 239.
    Use of uninitialized value $pathToDsym in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 245.
    Use of uninitialized value $dsymBaseName in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 245.
    Use of uninitialized value $executable in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 245.
    Use of uninitialized value $executable in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 245.
    Use of uninitialized value $executable in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 248.
    bad path 85629100-0000-0000-2000-006B00000000
    bad path 42609100-0000-0000-2000-006B00000000
    Use of uninitialized value $executable in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 268.
    Use of uninitialized value $executable in concatenation (.) or string at /usr/local/bin/symbolicatecrash line 268.

    When I run the one in the developer area (Xcode 4.01) it reports:
    find: Name.app: unknown option

    where “Name” is the second word of my app’s name.
    It, too, does not symbolicate my app.

    Reply
  9. Suraj
    October 3, 2013

    There is an app in appstore that I found, that helps to find and symbolicate crash logs.
    https://itunes.apple.com/us/app/symbolicator/id705354958?ls=1&mt=12

    Reply

Leave a Reply