Xcode 4 failure to symbolicate Crash Log

Asked 28/3, 2011 at 11:52 Answered 9/6, 2011 at 11:20

Solved iphone cocoa-touch xcode debugging adhoc

I have just updated my Xcode to X.Y.Z. 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.

Quarterdeck answered 28/3, 2011 at 11:52 Comment(1)

I have found a really nice way to fix this using Crittercism DSK. – Quarterdeck 27/9, 2011 at 10:28

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:

Spotlight settings to suppress unhelpful .app files

(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.

Gillam answered 30/3, 2011 at 19:34 Comment(7)

This is a good idea, till a proper fix is in place. I've filed a bug report with Apple, so we'll see how it develops. – Tavi 2/4, 2011 at 18:19

@Tavi - yeah, this is definitely an interim fix. Hopefully Apple will crack this in the next 4.5GB patch. :-) – Gillam 5/4, 2011 at 20:49

I had to add "~/Library/MobileDevice/Archived Applications" for it to work. – Undertrick 12/4, 2011 at 20:7

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. – Lightish 2/5, 2011 at 13:14

Rather than messing with Spotlight preferences I deleted all builds of the app in question from the above recommended directories and symbolication worked again for that app. I prefer this than potentially breaking Instruments and any other tools. Cheers! – Hooper 17/5, 2011 at 11:59

This didn't work for me - and deleting the DerivedData directory didn't work either. Seems to be more bugs in Xcode4 relating to this symbolication :( – Bathroom 2/6, 2011 at 9:10

I had to delete the "builds" directory after adding the above spotlight includes. Running the symbolicator from the command line (/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash) will show you where it's looking when it chokes. – Colville 28/7, 2011 at 23:58

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.

Vocalise answered 6/4, 2011 at 17:44 Comment(5)

This worked for me while the Spotlight/die changes didn't. Saved a lot of fiddling; Thanks a lot. Do not that you will need to replace symbolicatecrash at the full path if you want it to work in xcode (/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/) – Krahling 17/5, 2011 at 5:22

Your custom symbolicatecrash made my day while Spotlight exceptions did nothing. Nevertheless thanks everyone for all the useful answers! – Alphabetical 23/6, 2011 at 14:18

Warning: When I tried using this script it symbolicated my .crash file, but the symbols were all wrong. The methods shown in the stack came from entirely different parts of the code that were unrelated and out of context. I was ultimately able to get properly symbolicated output by copying my .app and .dSYM files out of my .xcarchive and placing them along side the crash report. I verified that Spotlight could find these files, then I dragged the crash report into organizer. – Miquelon 28/6, 2011 at 0:40

Great job, thanks a lot! Now all my crash reports symbolized even in XCode 4. – Jaclynjaco 2/9, 2011 at 11:29

@cduhn's comment should be an answer! it works on xcode 4.5.1 with osx 10.7! I've tried many other methods but all failed. – Marishamariska 19/2, 2013 at 14:55

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.

Brancusi answered 29/3, 2011 at 13:13 Comment(11)

@coob, Thank you for your answer. My app doesn't have any spaces in it's name. I simply can not find the dSym file after it finishes building the archive. If I reveal in Finder the application archive I just find a .xcodearchive file. No dSym or any other files. – Quarterdeck 29/3, 2011 at 13:18

Are you using XCode 3 or 4? I'm not familiar with 4, when I 'Reveal in Finder an archived application' on XCode 3 it shows me a directory like '1DE8BA58-B733-4FA6-88E0-8F9F71297070.apparchive' in '/Users/al/Library/Application Support/Developer/Shared/Archived Applications' which has the app, a plist and the dsym inside. – Brancusi 29/3, 2011 at 15:45

XCode 4 puts it in ~/Library/Developer/Archives. Then a directory by date, then an .xcarchive bundle. In finder, control-click to show package contents. dSYM is within dSYMs directory. App is within Products/Applications. All that said, I can't get XCode 4.0.1 to symbolicate a new crash log. – Cavern 29/3, 2011 at 19:54

@David, So let me understand this, you encountered this issue too? – Quarterdeck 29/3, 2011 at 20:43

Yes. I am having this problem. I was able to view crash logs fine with XCode 3.x but cannot with 4.0.1. I just did a test forcing a crash in my app. Does not symbolicate. I've opened a thread on the Apple developer forums. – Cavern 30/3, 2011 at 4:38

@David, Please, would you post back here what you find out on the Apple developer forum? – Quarterdeck 30/3, 2011 at 12:10

I can confirm that steps outlined here should solve the problem short term, i've posted about it on the Apple Dev forums also. Simon's suggestion about excluding these folders from spotlight is also a good long term suggestion – Tavi 2/4, 2011 at 18:10

And what do you do if your app DOES have a space in it? e.g. app is already live on the app store, I have a crash report, but Xcode refuses to symbolicate it. – Bathroom 2/6, 2011 at 8:58

@Bathroom did you find a way to symbolicate a crash report from an app on the app store that has a space in the name? I also have an apostrophe. Having a heck of a time getting this working. – Fifi 30/11, 2012 at 17:32

@JPK - No, I didn't. And Symbolicate STILL DOES NOT WORK in Xcode 4.5.x (it worked for 2 weeks, then stopped and has never worked since) - Apple refuses to fix it properly. They rely on their (badly broken) "index the whole hard disk" search demon, that is slow and badly written. And they provide no alternatives. ARGH! – Bathroom 2/12, 2012 at 13:45

@Bathroom Thanks. I have an app that I had to pull off of the app store.. it is crashing on startup on some users devices and I absolutely can't reproduce it no matter what I do. It is a Christmas app that I work on all year, and it is usually featured by Apple. Apple DTS responded once, telling me to do something I had already done, and I responded back and haven't heard back from them. I have crash logs that could help but I can't read them. It is a helpless and hopeless feeling, as my family depends on this income and it is just..gone. What's worse is that users who love the app have lost it. – Fifi 2/12, 2012 at 22:36

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.

Yoohoo answered 30/3, 2011 at 19:21 Comment(0)

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?

Fraud answered 30/3, 2011 at 18:13 Comment(1)

I have had some troubles with XCode 4.0 since it doesn't archive the same way as Xcode 3. It creates an xarchive, I then have to create a .ipa, and -as it was the way I did things in the past- pulled out the .app package from this to send to my tester. I think maybe xcode doesn't find the dsym since it is internal to the xarchive package itself. – Fraud 30/3, 2011 at 18:15

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)

Vasomotor answered 9/6, 2011 at 11:20 Comment(1)

Apple removed that link ... ARGH!! – Revert 13/1, 2012 at 8:17

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags