问题
I have just updated my Xcode to 4.0.1. Now I have a problem with the symbolication of the crash logs received from my tester and even from my phone too.
When I build the AdHoc distribution I am using the "Arhive" scheme, then I create the *.ipa file singing it with my developer credentials.
Is this the issue? And I can't find the dSym files for these AdHoc builds.
回答1:
Further to coob's answer, I find adding these directories to Spotlight's ignore list (System Preferences → Spotlight → Privacy) helps:
~/Library/Developer/Xcode/DerivedData/(Xcode 4 build artefacts)~/Library/Application Support/iPhone Simulator/(file system for the iPhone Simulator)
Like this:
(See this blog post for additional detail.)
Update: from a comment by joerick: "This works, but it also meant that Instruments.app couldn't find the debug symbols, so I had to remove DerivedData from the Privacy list to do some profiling." - bear this in mind if you use Instruments.
回答2:
For me, neither the line 323 edit nor the Spotlight exclusions fixed it. So I tracked down the issues in symbolicatecrash and published a patched version on github. Just replace /usr/local/bin/symbolicatecrash and your iOS crash reports will start symbolicating again.
This patch may not work for Mac apps, as it makes assumptions about the structure of the .xcarchive directory which don't appear to hold for desktop apps.
Edit: you may still have problems if Spotlight hasn't indexed your archives. You can get force an index by running the following in a terminal:
mdimport ~/Library/Developer/Xcode/Archives/
More info on troubleshooting here.
回答3:
The symbolication script is having an issue finding the right binary/dSYM. It uses Spotlight to do this and often cocks up. Here's a few things to try:
Make sure your .app doesn't have a space in it.
It may be finding the version of your app installed on the simulator (backwards, but it sometimes does this for me). Reset your simulator.
Clear your build directory.
回答4:
I had the same issue today. From my research on the web, there is an issue with the armv6 libraries that cause the symbolicate process to fail. I found the answer in the dev forums here.
For those without access, you need to create a copy of the symbolicatecrash script from /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/. Edit the file and replace the 'die' on line 323 with a 'print' (this is why it's not working, the script fails here).
Then run symbolicatecrash against your crash log. You'll see the error from line 323, but then it will symbolicate all your lines and variables. It still fails for the system libraries, but it give enough information to fix your own bugs.
Hope this helps.
回答5:
I think I had this issue, or something similar. Xcode 4.0 wasn't showing the symbols for a crash I had from a tester. I seemed to fix this by opening the xarchive that I had created, and copying out the dsym file from within it (right click and 'view package contents') to sit alongside it in the archive folder. I can't guarantee this was the solution - I was trying a number of other solutions at the time, but I know that I have the symbols now and didn't before. Worth trying?
回答6:
To locate a dSYM file based on it's ID in a crashlog that looks like this :
Binary Images: 0x100000000 - 0x100021ff7 +com.developer.foobar 1.1 (2) <D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8> /Applications/FooBar.app/Contents/MacOS/FooBar
you can do:
mdfind com_apple_xcode_dsym_uuids == D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8
For OSX apps built with "DWARF with dSYM" you do not actually need the dSYM file and can use the manual approach at https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS
Additionally to check the UID of a binary you can do something like
dwarfdump --uuid /Users/valexa/Desktop/GPSnote.app/GPSnote
UUID: 6194D2B0-4E61-3834-AD15-C279EB1848XX (armv7)
UUID: D1B7F956-7D79-3D4D-BA53-E9EBB368A9F8 (armv7s)
来源：https://stackoverflow.com/questions/5458573/xcode-4-failure-to-symbolicate-crash-log