Xcode Crash Organizer Does Not Symbolicate .Xccrashpoint Files

Xcode Crash Organizer does Not Symbolicate .xccrashpoint Files

Not ideal, but if you right-click an .xccrashpoint file, select "Show Package Contents", you can navigate its folder structure to find the actual .crash file which you can extract and then symbolicate through the command line using steps described here:

Run

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

Ensure that DEVELOPER_DIR is set:

export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

Can't symbolicate crash logs

The good news that it is crashing in your code, not in Operating Systems or Library code, so you have a good chance to debug it. Your code that is crashing is running off a timer. Sometimes these bugs are seen because in testing, you are just testing the app. But in the real world, those timers fire when you are not expecting them.

For example, someone ran your app, then put it into the background when using another app, or for example they received a phone call whilst using the app. If you attach the full contents of the .crash file, it will give more information on the cause of the crash.

Another thing you can do is place asserts into your code, such as in your timer callback functions for each object you are relying on being non-null.

You may find that your app is trying to draw onto the screen but is in the background. This is a common reason for a crash seen in the field for games that use timers. That may sound like a generalisation but it is a suggestion to try and make you think differently about the real world environment your customers face which can the reason for the failure.

Debugging .xccrashpoint

I have stumbled on this recently too. What helped me was:

• right click on the crash -> show in finder
• copy the .xccrashpoint file somewhere
• rename the file extension from .xccrashpoint to .crash
• now Finder sees it as a folder and you can browse to the .crash file you need

Then you need to symbolicate the crash. There are several ways to do this, but the easiest I know is to:

• open Window -> Devices panel in xCode
• Click on the device (I had to plug in iPad) -> open device logs
• drag and drop the .crash file there
• sort by date, find your crash, the crash is now symbolicated

Why aren't the crashlogs from Testflight symbolicating in Xcode?

Apparently this is a bug that started happening when Apple started accepting bitcode. Not all of the dSYMs are downloaded when you click on 'Download dSYMs…' in the Xcode organizer. Here's how I fixed it:

1. Manually downloaded the dSYMs from the build page in iTunes Connect
2. Right-clicked on the crash log in Xcode and opened it in Finder
3. The xcrashpoint file you'll find is an archive, so right-click and show package contents
4. Drill down to your .crash file(s)
5. Copy the .crash file(s) to a different directory, for instance the desktop
6. Copy the dSYMs folder you downloaded to the same directory
7. Open Terminal, cd to the folder
8. In terminal, set the developer dir path:

export DEVELOPER_DIR='/Applications/Xcode.app/Contents/Developer'

9. Then symbolicate the files with (replace your paths and filenames here):

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash name_of_crashfile.crash name_of_downloaded_dSYMs_dir/ > output.log

And voila! You have your symbolicated crash log.

XCode 4.6 organizer does not symbolicate my app crash stack trace

This article will help finding where the problem is: http://support.hockeyapp.net/kb/how-tos-faq/how-to-solve-symbolication-problems

Since you say you run in release mode, the version running on the device is NOT the one that you archived! So if there is a release build already available in the DerivedData directory, it will take that. Otherwise it will create a new build and install that one.

Now there are two possibilities why symbolication doesn't work:

1. You are doing another release build later on, so the previous build and dSYM get overwritten (see explanation in the link above)
2. Spotlight doesn't find the dSYM and app binary with the UUID written in the crash report (see explanation in the link above to verify that)

Update: Note regarding stripping symbols: when you don't strip the symbols as mentioned in your edited post, the symbolication is done on the device already. But of course you will be missing the line numbers.

---

Related Topics