Atos Does Not Symbolicate System Frameworks/Libraries Properly

Atos does not symbolicate system frameworks/libraries properly

The answer was so simple but sometimes you don't see it in front of you.

Instead of using the application's dSYM you use the framework of the iOS version that the device has when crashed. e.g. for the UIKit symbols of the iOS 8.1.1

xcrun atos -arch arm64 -o ~/Library/Developer/Xcode/iOS DeviceSupport/8.1.1 (12B436)/Symbols/System/Library/Frameworks/UIKit.framework/UIKit -l 0x18d5b0000 0x000000018d5f90b0

I may no longer symbolicate crashlog with atos

Apple answered me, apparently the old command those not work any longer; the right command is:

/Applications/Xcode.app/Contents/Developer/usr/bin/atos -arch arm64 -o * -l

atos and dwarfdump won't symbolicate my address

First of all check if the dSYM is really the correct one for that app:

dwarfdump --uuid kidsapp.app/kidsapp
dwarfdump --uuid kidsapp.app.dSYM

Both should return the same result.

Next check if the dSYM has any valid content

dwarfdump --all kidsapp.app.dSYM

This should give at least some info, other than not found.

I guess that the dSYM is corrupt. In general you might want to use a crash reporter that gives you a full crash report with all threads and last exception backtrace information. I recommend using something based on PLCrashReporter, e.g. QuincyKit (Open Source SDK + Server + symbolication on your mac) or HockeyApp (Open Source SDK + Paid service + server side symbolication) (Note: I am one of the developers both!)

iOS crash reports: atos not working as expected

You have to calculate the address to use with atos, you can't just use the one in the stacktrace.

symbol address = slide + stack address - load address
  1. The slide value is the value of vmaddr in LC_SEGMENT cmd (Mostly this is 0x1000). Run the following to get it:

    otool -arch ARCHITECTURE -l "APP_BUNDLE/APP_EXECUTABLE" | grep -B 3 -A 8 -m 2 "__TEXT"

    Replace ARCHITECTURE with the actual architecture the crash report shows, e.g. armv7.
    Replace APP_BUNDLE/APP_EXECUTABLE with the path to the actual executable.

  2. The stack address is the hex value from the crash report.

  3. The load address can be is the first address showing in the Binary Images section at the very front of the line which contains your executable. (Usually the first entry).

Since in the past value of the slide was equal to value of the load address this always worked. But since Apple introduced Address space layout randomization beginning with iOS 4.3 (in different variations), the apps loading address is randomized for security reasons.

Cannot fully symbolicate iOS crash log

Just a little update on this - I still can't get logs to symbolicate in Xcode (and as I've now moved my Xcode projects to a network drive I'm pretty sure I'll never get it to work), however I have found a decent enough solution in PLCrashReporter 1.2. It can locally symbolicate, which while not perfect, is normally specific enough to allow me to hone in on the problem.

PLCrashReporter 1.2 symbolication options

iOS Crash Symbolication

It turns out that I didn't have the system framework symbols for iOS 11.0.3 locally, so symbolicatecrash wasn't able to symbolicate the system framework symbols.

I was able to see that I didn't have the necessary symbols by referencing the answer to this question: Atos does not symbolicate system frameworks/libraries properly

Once I installed iOS 11.0.3 on my device and connected my device to Xcode, the symbols for iOS 11.0.3 were automatically downloaded and symbolicatecrash started working for the entire crash log.



Related Topics



Leave a reply



Submit