iPhone Crash Logs
Sometimes programs crash. This annoys users and developers alike. Users are frustrated because they cannot use crashing software, developers are frustrated because they have to hunt bugs instead of doing something creative and rewarding. How do we communicate if an iPhone application crashes?
I’ll start with a disclaimer. I’m not sure whether the information provided in this post is covered by iPhone Developer Program NDA or not. If it is, the post will be removed. Secondly, this post is a result of googling, so I haven’t invented anything new here.
Working with crash logs typically involves certain interaction between developers and users, unless they are automagically sent to the developer. First of all, the user should get the crash log and send it to the developer, who should examine it, find the bug and fix it.
iPhone OS and Mac OS X are remarkably similar architectures. Both store crash logs to help identify crashing bugs. The difference between the two is how users retrieve them. On Mac OS X every user has unrestricted access to crash logs related to the applications she runs. The iPhone does not even have a file browser. What to do? iTunes comes to the rescue.
Whenever you synchronize your iPhone or iPod Touch, all the crash logs are transferred to your computer. Here are their locations:
- Mac OS X :
~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME> - Windows XP:
C:\Documents and Settings\<USERNAME>\Application Data\Apple computer\Logs\CrashReporter/<DEVICE_NAME> - Windows Vista:
C:\Users\<USERNAME>\AppData\Roaming\Apple computer\Logs\CrashReporter/MobileDevice/<DEVICE_NAME>
The log file names start with application name and have the extension “crash”. They are just plain text files and can be sent by e-mail in original or zipped form, or even copy-pasted into your e-mail program.
The second part is trickier. Both Apple and common sense suggest that all AppStore binaries are shipped with stripped symbols. If you ever saw a crash log like this, read on:
Thread 0 Crashed: 0 libobjc.A.dylib 0x300c87ec 0x300bb000 + 55276 1 MobileLines 0x00006434 0x1000 + 21556 2 MobileLines 0x000064c2 0x1000 + 21698 3 UIKit 0x30a740ac 0x30a54000 + 131244 4 UIKit 0x30a66110 0x30a54000 + 74000 5 UIKit 0x30a6565c 0x30a54000 + 71260 6 GraphicsServices 0x3169b0b4 0x31696000 + 20660 7 GraphicsServices 0x3169d818 0x31696000 + 30744 8 IOMobileFramebuffer 0x31f3e8f8 0x31f3d000 + 6392 9 com.apple.framework.IOKit 0x30f342b8 0x30f30000 + 17080 10 CoreFoundation 0x3025ced4 0x30229000 + 212692 11 CoreFoundation 0x3025bed6 0x30229000 + 208598 12 CoreFoundation 0x3025b584 0x30229000 + 206212 13 GraphicsServices 0x316998e4 0x31696000 + 14564 14 UIKit 0x30a5e308 0x30a54000 + 41736 15 UIKit 0x30a671dc 0x30a54000 + 78300 16 MobileLines 0x00002090 0x1000 + 4240 17 MobileLines 0x0000202c 0x1000 + 4140
In a nutshell, it contains function addresses and offsets instead of function names and line numbers. The structure is obvious, but, to be honest, I don’t know what “MobileLines 0×00006434 0×1000 + 21556″ is, even though I have all the source code. Thanks to Apple Developer Tools and to Craig Hockenberry who wrote about it, we have a perfect solution called symbolicatecrash.
I copied it to /usr/local/bin/ so that I can run it whenever I want without trying to remember its original location (you may prefer a symbolic link):
$ sudo cp /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/Resources/symbolicatecrash /usr/local/bin/
Running this script with the -h option provides the minimal help:
$ symbolicatecrash -h
usage:
   symbolicatecrash [-Ah] LOGFILE [SYMBOL_PATH ...]
   Symbolicates a crashdump LOGFILE which may be "-" to refer
 to stdin. By default, all heuristics will be employed
 in an attempt to symbolicate all addresses. Additional
 symbol files can be found under specified directories.
Options:
   -A  Only symbolicate the application, not libraries
   -h  Display this message
   -v  Verbose
To add symbols to the crash log you need the dSYM file generated by the linker when you compiled your application for AppStore. In other words, when you build for AppStore you should keep the dSYM package in a safe place backed up by Time Machine. This is very important. You should keep a copy of the dSYM for each version of your application ever shipped. If you have the package, translating code offsets to function names with line numbers has never been easier:
$ symbolicatecrash report.crash MobileLines.app.dSYM > report-with-symbols.crash
Here is the result:
Thread 0 Crashed: 0 libobjc.A.dylib 0x300c87ec objc_msgSend + 20 1 MobileLines 0x00006434 -[BoardView setSelectedPiece:] (BoardView.m:321) 2 MobileLines 0x000064c2 -[BoardView touchesBegan:withEvent:] (BoardView.m:349) 3 UIKit 0x30a740ac -[UIWindow sendEvent:] + 264 4 UIKit 0x30a66110 -[UIApplication sendEvent:] + 248 5 UIKit 0x30a6565c _UIApplicationHandleEvent + 4088 6 GraphicsServices 0x3169b0b4 PurpleEventCallback + 428 7 GraphicsServices 0x3169d818 HeartbeatVBLCallback + 152 8 IOMobileFramebuffer 0x31f3e8f8 IOMobileFramebufferNotifyFunc + 124 9 com.apple.framework.IOKit 0x30f342b8 IODispatchCalloutFromCFMessage + 304 10 CoreFoundation 0x3025ced4 __CFMachPortPerform + 72 11 CoreFoundation 0x3025bed6 CFRunLoopRunSpecific + 2364 12 CoreFoundation 0x3025b584 CFRunLoopRunInMode + 44 13 GraphicsServices 0x316998e4 GSEventRunModal + 268 14 UIKit 0x30a5e308 -[UIApplication _run] + 404 15 UIKit 0x30a671dc UIApplicationMain + 1064 16 MobileLines 0x00002090 main (main.m:16) 17 MobileLines 0x0000202c start + 44
Now, this is much better. Happy debugging!
Other useful references:
1. raoli.com » Blog Archive » links for 2008-09-25:
September 26th, 2008
at 01:04
Link
[...] Whatever » Blog Archive » iPhone Crash Logs iPhone crash log locations on OS X and Windows (tags: iphone fuckingnda crashlog) [...]
2. Symbolication at Under The Bridge:
October 16th, 2008
at 06:48
Link
[...] we have a good post for your attention on how to diagnose iPhone crashes in the wild after the fact. Salient points are [...]
3. restoroot.com » Blog » Crash Reporter for iPhone Applications:
October 18th, 2008
at 23:16
Link
[...] On the iPhone you can’t access the crash report file form your application because it’s running in a sandbox. iTunes syncs the crash reports of all application, so in theory a user can send it to you, but this seems rather complicated to me (Locations of Crash Logs). [...]
4. Josh:
October 24th, 2008
at 21:38
Link
Konstantin..
Thanks for this great writeup. I made sure to snapshot my .dsym files last time i submitted a new build to the app store. This morning i had a user send me a crash dump and i’m having trouble getting it “symbolificated”. When i run the command it matches up all of the framework calls but none of my code. Have you had this happen?
5. Konstantin:
October 25th, 2008
at 12:21
Link
Josh, I haven’t seen it fail. The only reason I can imagine is that the .dsym file does not match the binary. This may happen if you built your project again after archiving the .dsym or if you ran the tool against a different binary. For example, in my “build” folder I have both “AppStore-iphoneos” and “Release-iphoneos” folders because I have a separate provisioning profile for AppStore. For some reason I cannot explain these binaries differ even though their build configurations are identical except for the provisioning profile.
You can make a test application which always crashes and try to symbolicate a crash report to make sure the tool works on your machine as expected. If such a test fails, you have definitely stumbled upon a bug.
6. Dave Haupert:
October 26th, 2008
at 07:21
Link
I’m having the same problem as josh. I have a .dsym file and when I run the script it doesn’t give any errors, but the output is basically the same as the input crash log. I read on Hockenberry’s website (furbo.org) that if the path to the .dsym file had a space the script would fail due to a bug in it. But my path has no spaces. I tried running script with the -v (verbose) option and this is what it says:
Symbolicating…
11795 characters read.
0 binary images referenced:
OS Version 5F136
Arch of Logfile: armv6
0 binary images remain after pruning:
Finding Symbols:
done.
0 binary images were found.
–
While there are no errors listed there, the fact that it says 0 binary images were found means something is amiss.
Any ideas? What does it say when you run with the -v command on a working symbolicatecrash?
Thanks in advance for your help and thanks for posting this potentially great information!
7. Konstantin:
October 26th, 2008
at 11:47
Link
Dave, on my machine it says:
Symbolicating…
8457 characters read.
47 binary images referenced:
…
OS Version 5C1
Arch of Logfile: armv6
6 binary images remain after pruning:
WebCore, libSystem.B.dylib, GraphicsServices, UIKit, CoreFoundation, MobileLines,
Finding Symbols:
…
Hmmm, I noticed that Apple has updated the script. Are you running the latest version? I guess something fails in parse_images subroutine. You might uncomment print STDERR on line 389 to see what images it finds. As far as I can see, there even may be problems parsing the crash log file itself due to certain symbols in the application name. Too bad I can’t parse perl scripts.
8. Dave Haupert:
October 26th, 2008
at 17:59
Link
I’m still using the 2.0 SDK for maximum device compatibility. Guess it’s time to switch to the 2.1, or are you even referring to the 2.2 SDK? Perhaps there is somewhere I can download the latest script from the web? Sorry to be a pest, but hopefully we can find the root cause that others may see in the future and can document a fix for it right here!
9. Konstantin:
October 27th, 2008
at 10:35
Link
Dave, can you send me your crash report (dev *at* anoshkin.net)?
10. MORTEN:
December 10th, 2008
at 18:30
Link
Hey, Dave and Konstantin – did you figure out the problem? I have the same thing going on here…
ThX
11. Konstantin:
December 12th, 2008
at 10:48
Link
I think so (though Dave forgot to confirm it). Dave was facing two problems. The crash log came from iPhone OS 2.2 and was corrupted. Since Dave hadn’t installed SDK 2.2, symbolicatecrash could not find any system library symbols.
12. XCode builds and SVN - BigSprocket:
December 15th, 2008
at 06:32
Link
[...] For more on this problem and how to use symbolicatecrash, see the excellent articles here and here. [...]
13. halbert:
December 31st, 2008
at 10:21
Link
Hello,
I’m having a similar problem Josh is having. The cocoa framework calls match, but none of my app call matches. I’m running iPhone OS 2.2 and SDK 2.2. I ran the symbolicatecrash in verbose mode and noticed one thing:
………fetching symbol file for TestCrashLog–[undef]
Searching []…– NO MATCH
Searching in Spotlight for dsym with UUID of /var/mobile/Applications/A59C6CEB-30CA-4E40-98EE-D1B080D2F0DE/TestCrashLog.app/TestCrashLog
Running mdfind “com_apple_xcode_dsym_uuids == 78375A1D-9645-99CC-2208-A3F56DD04DDB”
dsym directory: \/Users\/halbert\/Documents\/dev\/iphone\/TestCrashLog\/build\/Release\-iphoneos\/TestCrashLog\.app\.dSYM
paths: /Users/halbert/Documents/dev/iphone/TestCrashLog/build/Release-iphoneos/TestCrashLog.app{,/TestCrashLog,/Contents/MacOS/TestCrashLog}
Did not find executable for dsym
## Warning: Can’t find any unstripped binary that matches version of /var/mobile/Applications/A59C6CEB-30CA-4E40-98EE-D1B080D2F0DE/TestCrashLog.app/TestCrashLog
It looks as though its not finding the corresponding binary to the dsym. However, its in the same location as the dsym, so I’m not sure why I would be having this problem.
Any ideas?
Thanks
14. halbert:
December 31st, 2008
at 10:41
Link
hello,
I believe I have found a solution to my problem above. Apparently there is a bug in the symbolicatecrash script w/ finding .dsym and binary files that indeed exist. You can read about it here and d/l a modified version of the script that fixes the problem:
15. Ben’s Dev Blog » Stack Traces for iPhone development:
January 29th, 2009
at 03:59
Link
[...] error. If you’re looking to piece together a crash when your device wasn’t plugged in, Konstantin Anoshkin put together a nice post on how to symbolicate a crash log which will make it readable in much the [...]
16. iPhone OS - Crash Logs | MacManitou's Blog:
February 4th, 2009
at 18:53
Link
[...] How to gather crash logs from an iPhoneOS device  and how tp read the crash log. Thanks to Konstantin Anoshkin who has put this help together: http://www.anoshkin.net/blog/2008/09/09/iphone-crash-logs/ [...]
17. iPhoneã?§Crash Logã?‹ã‚‰é–¢æ•°ã?®ä½?置を特定ã?™ã‚‹ — sklave:
March 14th, 2009
at 22:46
Link
[...] �����symbolicatecrash�解説����詳����。 [...]
18. iPhone SDK Examples | Universal Creators:
June 14th, 2009
at 21:31
Link
[...] crash logs If you’re in the unfortunate position of having to decipher a crash log, navigate here to give them [...]
19. location of error log files? - iPhone Dev SDK Forum:
July 10th, 2009
at 20:46
Link
[...] screen with no messages in the console. (just trying to present a modal view controller). h/t to Whatever Blog Archive iPhone Crash Logs for this info: You have to sync your device, then the crash logs will be at:Mac OS X : [...]
20. ciukes:
July 15th, 2009
at 04:47
Link
You shouldn’t be worried about legal issues. What you have described is covered by Apple’s Technical Note TN2151 “Crash Reporting for iPhone OS Applications”
http://developer.apple.com/iphone/library/technotes/tn2008/tn2151.html
21. Let's Talk iPhone » XCode builds and SVN:
September 2nd, 2009
at 00:34
Link
[...] more on this problem and how to use symbolicatecrash, see the excellent articles here and here. Tags: Comments (0) Trackbacks (0) Leave a comment [...]
22. Googler:
September 9th, 2009
at 19:13
Link
Hi,
This is gr8 blog,
but I have problem to check crash report
can you please guide me. how it works.
i am copy symbolicatecrash to this location.
/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/Resources/symbolicatecrash
now what i am doing to decode log.
23. GTekna » How to get an iPhone application crash log:
September 9th, 2009
at 22:52
Link
[...] iPhone Crash Logs Categories: Uncategorized Tags: crash, debugging, iPhone, iPod Touch, log Comments (0) [...]
24. Did you | Thirstysea:
September 17th, 2009
at 08:45
Link
[...] the good folks on internet here and here have already taken care of explaining in detail the debugging steps, I still required the dSym [...]
25. Hardy:
October 7th, 2009
at 16:09
Link
In SDK 3.0 the symbolicatecrash has been moved to /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/
26. » HowTo: AdHoc distributing an iPhone app petersteinberger.com:
October 11th, 2009
at 18:55
Link
[...] You can find out more about symbolification here, here and here. [...]
27. Hasnat:
November 29th, 2009
at 21:45
Link
good tutorial but resources location was different for me
am using 3.1.2 SDK
28. Links for when your iPhone app crashes:
January 19th, 2010
at 03:54
Link
[...] http://www.anoshkin.net/blog/2008/09/09/iphone-crash-logs/ [...]
29. » Crash Reports on the iPhone petersteinberger.com:
February 2nd, 2010
at 05:18
Link
[...] tell your Tester to zip and send the crash logs. They won’t even find [...]