You will need your released app’s dSYM bundle. Since you are a good developer, whenever you release a version of your software, you use Xcode’s built in Archive functionality, so you don’t have a problem with that. (Right?)

So open Xcode’s Organizer. Right click on your archive, and pick “Show in Finder.” Then right click on the archive, and choose “Show Package Contents”.

Enter the “dSYMs” subfolder, and find the sole .dSYM bundle in there. Right click on it, and “Show Package Contents”. Open Contents, Resources, DWARF — and you’ll reach the file that actually contains the debug symbols. For example, “GeorgesGreatApp”, without any extension. Wheeee!

Now, open Terminal. Punch in atos -o and drag and drop the “GeorgesGreatApp” file (the one that contains the debug symbols) into the terminal. Then punch in -arch x86_64 (or whatever architecture the crash occurred on). Finally, paste the address that you want to know more about.

For example, given the following line in the crash log:

1   net.vucica.GeorgesGreatApp    	0x0000000100001e91 0x100000000 + 7825

you’d take the first hex number that appears on that line, and have this on the command line:

atos -o /Users/YOURUSERNAME/Library/Developer/Xcode/Archives/2012-02-29/GeorgesGreatApp\ 29.02.2012.\ 00.40.xcarchive/dSYMs/GeorgesGreatApp.app.dSYM/Contents/Resources/DWARF/GeorgesGreatApp -arch x86_64 0x0000000100001e91

and you’d get this output:

-[GGAppDelegate generateThumbnailsForJpeg:] (in GeorgesGreatApp) (GGAppDelegate.m:326)

Extremely handy when Xcode screws up symbolication or outright refuses to import the crash log. Maybe it’s Xcode’s fault. Maybe Spotlight did not correctly index dSYM’s location. Maybe Spotlight did not correctly index .app’s archived location. Whatever it is, I don’t really care — if symbolication is broken, it’s broken. But at least I can use the underlying mechanism in atos.

–
via blog.vucica.net