1

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

  • define the developer directory: export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer”
  • install the utility from its original directory: sudo cp /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash /usr/bin
  • put the dSYM file, the .app file and the .crash file in the same folder
  • symbolicatecrash “FILENAME.crash" "FILENAME.app" "FILENAME.app.dSYM"

2| atos - command line utility

  • open crash file, get the memory address one line at a time from the stack trace, like so: 8 NAME_OF_MY_APP 0x000ad031 0xa7000 + 24625
  • and use atos to symbolicate that one line: atos -arch armv7 -o NAME_OF_MY_APP.app/NAME_OF_MY_APP 0x000ad031 0xa7000 + 24625

3| gdb

Now either I'm dumb, stupid, or both but for me, the problem with all these methods is that they inconsistent.

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.

Is the exception description even in the crashlog?

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?

Zoltán Matók
  • 3,923
  • 2
  • 33
  • 64

1 Answers1

2

  1. symbolicatecrash - command line utility

    You are calling the script wrong, it should be:

    symbolicatecrash “FILENAME.crash" "NAME_OF_MY_APP.app.dSYM"

  2. 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)

Troy
  • 690
  • 1
  • 7
  • 25
Kerni
  • 15,241
  • 5
  • 36
  • 57