‘symbolicatecrash’ is the Developer Tools utility which replaces all those meaningless addresses from crash logs with actual symbol names and source code references. It lives at some obscure folder within /Developer – use find to dig it up and symlink it into /usr/local/bin if you wanna use it conveniently from the command line.

Anyway, after plenty of frustration, I noticed some chatter about the damn thing being busted in Xcode 4. Figures!

There’s an [alternate third party version](https://github.com/fourdman/symbolicatecrash-fix) on GitHub, but this didn’t really help me – I still got inscrutable errors, so I took a look at the original.

The version that comes with Xcode 4 appears to have some problems distinguishing, say, an iPhone Simulator build of the app from a native build sitting in the Archives folder. I’d just see an error about otool and some binary living in the iPhone Simulator folder.

Digging into the errant symbolicatecrash source, I noticed that the code that finds the executable path tests each candidate using otool, but doesn’t seem to be able to comprehend the output from otool caused by running it on the wrong architecture.

So, replacing the rather unhelpful ‘die’ statement on line 323:

die "Can't understand the output from otool ($TEST_uuid -> '$otool -arch $arch -l $path')";

With a “No, it ain’t this executable” response:

return 0;

…solves the problem immediately. Now I can drag crash logs straight into the Organizer in Xcode, and it’ll symbolicate correctly.