Soo, with TestFlight's end it has become even more pressing to be able to fully understand iOS crashlogs.
There are numerous questions here at SO about this topic but in my experience none of the solutions provided enough insight into the crash itself. There still seems to be quite a confusion about this in the iOS world.
For the sake of completion here are the methods and steps I found and took.
(Disclamer: I had access to everyting: the .app file, the .dSYM and .crash files)
1| symbolicatecrash - command line utility
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer”
sudo cp /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash /usr/bin
dSYM file, the .app file and the .crash file
in the same foldersymbolicatecrash “FILENAME.crash" "FILENAME.app" "FILENAME.app.dSYM"
2| atos - command line utility
8 NAME_OF_MY_APP 0x000ad031 0xa7000 + 24625
atos -arch armv7 -o NAME_OF_MY_APP.app/NAME_OF_MY_APP 0x000ad031 0xa7000 + 24625
3| gdb
In my experience, symbolicating with symbolicatecrash
will give us the method names for all the stack trace, but no line numbers and little to no info about the exception thrown.
Atos
is a bit more descriptive, but still no exception description and you have to manually do this for all the lines you want symbolicated.
Also, atos
sometimes points to method calls that are not in output of symbolicatecrash
...
When I uploaded a build to TestFlight along with the .dSYM they could give me precise method names, line numbers and exception description that I just cannot find in these symbolications.
Do we have to implement an unhandled exception handler within the app and send the reports "home" (ie to a web server?) to have access to what exception was thrown, where?
symbolicatecrash - command line utility
You are calling the script wrong, it should be:
symbolicatecrash “FILENAME.crash" "NAME_OF_MY_APP.app.dSYM"
atos - command line utility
This call is also wrong:
atos -arch armv7 -l LOAD_ADDRESS_OF_THE_APP -o NAME_OF_MY_APP.app.dSYM 0x000ad031
Where LOAD_ADDRESS_OF_THE_APP
is the first address shown in the Binary Images
section for your app. See also: iOS crash reports: atos not working as expected
Now regarding the additional questions/remarks:
Line number not appearing using symbolicatecrash
:
This is because you passed along the app binary, which mostly has all symbols stripped (due to size) and even if the symbols would not be stripped it would never show line numbers. Always use the dSYM for symbolication if you have it.
Exception description missing:
In most cases, Apple's iOS crash reports do not provide the Application Specific Information
block in the reports which would contain that information. If you only have Apples crash reports, there is nothing you can do.
Some additional information:
Symbolication system calls
You will need the symbols of the specific CPU architecture and iOS version the crash report was created with. So you would need at least an armv7 device and an arm64 device with the specific iOS version and having those at least once connected to Xcode that it could import the symbols. Otherwise there will be symbols left unsymbolicated in the report.
Let Xcode symbolicate it
If your system is setup correctly, all you need to do is drag the crash report into the top Devices Logs
entry in the Xcode organizer and it will call symbolicatecrash for you and find the correct dSYM via Spotlight. (Requires the dSYMs folder to be indexed by Spotlight)
Alternatives to collect crash reports
There are multiple alternatives out there to collect crash reports. Open Source solutions, free services and paid services that provide SDKs to collect the crash reports in your app and send them to a server, symbolicate and group them automatically. (Disclaimer: I am the developer of QuincyKit Open Source project and Co-Founder of HockeyApp.net service)