Related pages:

The information in most raw crash stack traces is not fully human-readable. To make your crash stack traces more easily understood, you need to provide a platform-specific mapping file that can translate the raw data into human-readable output. Normally, you upload the file at the time that you instrument your mobile application.

This page explains the advantages of providing these files.

iOS dSYM File

For iOS applications, the raw data in the stack traces in crash snapshots consists of memory addresses of stack frames that point to executable application code. It also includes symbols and memory offsets for the system library code used by the application. Such a partially symbolicated stack trace looks something like this:

iOS dSYM File

AppDynamics attempts to display stack traces with the names of functions with offsets into those functions to help you identify the line of code that was executing when the application crashed. To get the symbols that map to the executable code, it needs the dSYM (desymbolication) file for the crashed application.

If the dSYM file for the crashed application has been uploaded, the symbolicated stack trace shows the function name and the offset into the function where the app crashed. It looks something like this:

iOS dSYM File

The dSYM file is created when the application source code is compiled with the Debugging Information Format set to DWARF with dSYM file. AppDynamics recommends that you build all the iOS apps that you want to monitor using this option and then upload the dSYM file to AppDynamics. The best time to do this is when you instrument the app.

If a dSYM has been uploaded for a crashed application, in the crash list the Symbolicated column for the associated crash snapshot is true.

If the symbolicated property is false and you want to see user-friendly stack traces in your crash snapshots for this application, you need to locate and upload the dSYM file for the crashed application.

ProGuard Mapping File for Android

If an Android app was not obfuscated to prevent reverse engineering, you should see human-readable stack traces in your crash snapshots by default.

If the code was obfuscated, however, AppDynamics needs the ProGuard mapping file to be able to deobfuscate the app. The best procedure is to upload this file at the time you build the app.

If a ProGuard mapping file has been uploaded for a crashed application, in the crash list the Deobfuscated column for the crash snapshot is true.

If the deobfuscated property is false and the stack traces you see in the crash snapshots are obfuscated, you need to locate and upload the mapping file for the application.