I was recently investigating one very strange crash in an app I’m working on. The app is distributed ad-hoc (through wonderful TestFlightapp.com) and each release is archived in Xcode 4.2. I got the
.crash file from beta tester and dragged it into Xcode’s Organizer, which did symbolicate everything in the stack except two lines from my code.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
Great. The usual reason for this is that Xcode did not find
.dSYM file. This is actually really strange since Xcode has the
.xcarchive, saved in its default location. But no matter what I tried, it did not symbolicate properly. One possible reason that I’ve seen people mention is that Spotlight has not indexed the archives and you can force this with this Terminal command:
This did not help either. I tested Spotlight and strangely it could not find the app signature (from the bottom of the crash log excerpt above):
At this point I tried to do it manually and in series of attemps encountered all kind of possible issues.
First, I had a custom
symbolicatecrash script in
/usr/local/bin/ from several months ago. This script often changes as Apple devs fix bugs in it. While they do that and ship the fixed version with next Xcode update, good souls on the internet have already resolved the given issue. Thus at some point I downloaded one of those custom versions and placed it there. Hence when I tried to run
symbolicatecrash manually, it used that version. You can check this in Terminal, by typing
which symbolicatecrash - if it finds the script anywhere in your default paths, it will show it. If not, then you are ok.
Second, in Xcode 4.2, the current version of this script is at this location:
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash. Files in this private framework are not accessible from any other folder, so in order to run it manually you need to either use this full path or copy it to the folder where you acquired
.crash log files are and run it from there.
Third, I extracted the .app and .dSYM file from the archive and placed in the same folder. I then tried to run the script from there, with all of these line (one by one):
None did anything differently. Things began to look really crazy at this point and I started doubting is this a crash report really from this version. Double-checked with tester, also double checked the .app.dSYM file as described here on Stack Overflow. All was fine, this was the binary used.
Forth, I tried to directly look for the given hex address in the crash log:
And this finally gave me what I needed:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
Or so I thought. When I looked into my code at this line, this was in
dealloc method, where
NSPersistentStoreCoordinator was released. And that was really nutty place to have a bug. At this point I was completely stumped and had no idea what else to try.
Luckily in this case, tester was able to give login credentials so I could repeat the scenario using his data, while debugging the app on the device. And found that I had a badly formatted NSPredicate which worked in 99.9% of cases and this tester stumbled on 0.1% where it did not. Great find, it would be a serious head-scratcher if app went live with this.
But I still don’t understand why Xcode 4.2 won’t see the
.dSYM file and while the script itself won’t symbolicate this
.crash log. Honestly, I can’t help but think this is seriously more complicated than it needs be. But it is as it is. Here some other useful stuff I encountered while working on this.
Place where Xcode puts
.crash logs picked from your testing devices:
~/Library/Logs/CrashReporter/MobileDevice/<your device name>.symbolicated
Various possibly helpful links:
If you have any ideas that could help, please write in comments.