On Mar 31, 2009, at 6:16 PM, Jerry Krinock wrote: Have you ever crashed a stripped build of a .app and seen symbol names in the Crash Report? I have, and always worried that my strip phase was not working.
After doing some experiments today, I've concluded that this is a "feature" of Crash Reporter: It looks for a nearby .dSYM file to symbolize a crash report. It does not always work. It seems to depend on the particular order of build, clean and strip.
I don't really care to know exactly how to reproduce. I'm just happy to know that when I see symbols in a Crash Report of a stripped product running on my Mac, I don't need to worry about my strip phase any more.
It's smarter than that.
Every dSym is built with a UUID that corresponds to a UUID in a Mach-O section in the binary that it's derived from. A Spotlight importer indexes the UUIDs of every dSym file that is in a Spotlight-accessible location on your Mac.
Xcode, gdb, CrashReporter, Instruments, Shark, and other tools that have to symbolicate a binary can read the UUID from the binary, look it up in Spotlight, and find the symbol file no matter where you put it.
This lets you, for example, keep a repository of dSym files for every released copy of your app, and symbolicate crash reports from users automatically, without having to keep track of which crash came from which version. And it happens automatically.
As you might intuit, the main thing that would cause it not to work is if you cached the dSym file in a location that you've protected from Spotlight indexing, or if you've turned indexing off.
Chris |