Atos Cannot Get Symbols from Dsym of Archived Application

Atos cannot get symbols from dSYM of archived application

To properly get symbols from your archived app's dSYM file and get useful information from your BugSense crash reports (or any other crash reports for that matter):

1. Copy the stack trace from BugSense into TextEdit or any other text editor. Make sure to use the "clipboard" icon, rather than simply copying the text. Otherwise you will not get the actual memory locations of the stack trace, which are necessary to look up the references using atos and symbolicate your stack trace.
2. Open XCode and go to the Organizer
3. Find your archive and right-click it, go to open it in the finder.
4. Navigate to the directory of the archive, usually ~/Library/Developer/XCode/Archives/YYYY-MM-DD/
5. Go into the specific archive, and then the dSYMs folder
6. You will see the file MyApp.app.dSYM and you may think, this is the file that I should run atos against! This is incorrect. It is actually another package! cd into this package, into the folder: MyApp.app.dSYM/Contents/Resources/DWARF and you will find another file simply called MyApp. This is the actual dSYM file.
7. Run atos -arch armv7 -o MyApp 0x0000000 (or whatever the memory address is) to find the location of your error, or simply atos -arch armv7 -o MyApp to enter interactive mode.

Why is the atos command unable to find symbols for my iOS crash log?

The dSYM file/dir must be the exact same one that was created when you built your submitted app-store build. Even another one built from the exact same code-base won't match against your crash-log.

Some potential causes:

• You built and tested your app and once you decided it was fine you saved the binaries (.app and .dSYM), then you rebuilt with appstore signing and forgot to archive THAT version of of the .app and .dSYM. Now your archived version won't match with crashes form the appstore version.
• You are trying to symbolicate using a freshly-built .app and .dSYM from source-control. You need to use the same .app and .dSYM that were submitted.

If you do have the correct dSYM anywhere on your computer (and the correct iOS debug info installed) then Xcode will automatically find it and create a symbolicated copy of the crash-log when you import the crash-log. It does this using spotlight to find a unique string that's generated at build time (this is why the exact version is needed for it to match). Note that the matching .app file also needs to be present.

Best practice is to build and test a release version, then re-sign it for submission (rather than submitting a separate build for app-store signing). This way you can preserve the correct .app and .dSYM somewhere safe. I put them in source control and tag it with the release number.

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.

atos gives ___lldb_unnamed_function

You have to call atos with the dSYM package, not the app bundle since that normally has the symbols stripped!

So the call is:

xcrun atos -l 0x97000 -arch armv7 -o myarchive.xcarchive/dSYMs/MyApp.app.dSYM 0x001357dc 0x00134446 0x00240cec 0x002416ea 0x0023e2de 0x000de724 0x00144f1a 0x00144336 0x000b1024 0x0009d464

Symbolicating iOS .crash file

There are multiple things:

1. The crash is caused by an exception and the crash report does not show the required Last Exception Backtrace.

2. Symbolicating the main thread will only show you the main.m call in frame 12 and the uncaught exception handler in frame 2 of thread 0

3. The crash report is written by an old version of PLCrashReporter (identified by the two [TODO] texts on top) or you are using another server for uncaught exceptions. As is, the crash report will not help you.

4. You should use atos with the apps dSYM instead of the app binary. Using the app binary will never show you filenames or line numbers and will only show you class name and methods if you don't strip symbols from the executable. But you should strip them from the executable to keep the binary size as low as possible (saves 30-50%).

5. The way you are calling atos is wrong. 0x7f68bb0 0x3017d000 + 84904 is not a valid option, and in fact your crash report doesn't even contain that. Instead you need to use only the first address after the binary name per frame. So for the following line:

    2   Example                               0x001ffe3b 0x4000 + 2080315
   

   You would use atos as follows:

    `atos -arch armv7 -l 0x4000 -o Example.app.dSYM 0x001ffe3b`
   

You should update your crash reporting SDK to use the latest PLCrashReporter version and make sure exceptions are shown properly in the report.

Fabric requesting dSYM that's not in archive or iTunes Connect dSYM file

You're almost there when you download the DSYM package from iTunes Connect! After downloading, add a .zip extension, and double click to unzip it.

In the folder of DSYMs produced, there will be one titled 65cbd90a2b443d36ab7a6a419b797a71 (the one Crashlytics is asking for). If it's not there - double check you are looking at the same builds on Crashlytics and iTunes connect.

Upload just that file to Crashlytics.

Problem solved. /p>

---

Related Topics