CODEWITHSUNDEEP
ioscrash-reports
0x6d6e
0x6d6e

Reputation: 153

How does crash reporting tools on iOS desymbolicate the crash reports on a release build?

On iOS, the Debug symbols are stripped from the release binaries for security reasons. So how does a crash reporting tool like Fabric,Hockey etc "desymbolicate" and show a nice stack trace of the crash point from a release build???

Do they capture/trace the crashes on their own, rather than relying on OS generated traces?

Upvotes: 0

Views: 791

Answers (1)

Kerni
Kerni

Reputation: 15329

The following applies to OS X, iOS, tvOS and also watchOS:

  1. If binaries themselves are containing symbols, they can only provide class name and method names. But never filenames or line numbers. So their benefit is limited but the increase in binary size is big, ~30-50% bigger (estimations, can be larger or smaller depending on the app)
  2. If your build settings are setup properly (default settings = DEBUG_INFORMATION_FORMAT set to DWARF with dSYM File), then ever single time you do build you'll also get a dSYM package with a dwarf file that contains everything needed to symbolicate and also getting filenames and line numbers.

So how do iTunes Connect, Xcode, Fabric, HockeyApp and others actually do symbolication?

They are all using the dwarf files in the dSYM package. They take the memory address from a stack frame, find the corresponding binary image in the Binary Images section of the crash report by matching the address ranges, take the UUID of the binary image, find the dSYM package which contains the matching UUID for the matching CPU architecture and then run a tool like atos against it to get the (demangled) symbols.

And how do they get the stack traces?

  1. The OS generates crash reports out of process which get used by iTunes Connect and Xcode.
  2. All 3rd party systems need code added to the app which sets up crash handlers for signal based crashes and unhandled exceptions and at crash time try to safely fetch all information needed in a crash report. This code runs in the apps process and therefor may not do a lot of things (e.g. it may not allocate memory at crash time) to safely collect that data and not destroy any users data or cause a device deadlock. 3rd party systems can not get the system generated crash reports, because those are located outside of the apps sandboxes.

Upvotes: 2

Related Questions