Crash symbolication

Follow

Introduction to symbolication

When releasing your mobile app, you might have come to the conclusion that you would like to either obfuscate your application or reduce the size of it by optimizing the bytecode. A benefit that would come out of these actions is that this would make your application also harder to reverse engineer.

For whichever reason you might have to do that, the result is that you now receive error stack traces that have obfuscated information in them, making it impossible to track down the source of your crash.

Depending on the platform, your stack trace would be full of memory addresses or transformed function names. Symbolication is the process of converting those into human readable, class/method names, file names, and line numbers.

You may view a tutorial about how symbolication works below.

Symbolicating iOS and Android crashes with Countly

Enterprise feature

Crash symbolication is available for Enterprise Edition users.

For the obfuscation process to be reversible, a symbol or mapping file is also produced while building your application. It is imperative for you to keep and archive those files as the symbolication process is only possible with them. You will also need to archive symbol files for every version you would like to symbolicate.

Currently, Countly supports symbolication for dexguard, proguard in Android and Apple provided tools in iOS mobile applications.

Android symbolication sample:

Sample Android Symbolication input Sample Android Symbolication output
java.lang.IllegalStateException: Could not execute method for android:onClick
at android.view.View$DeclaredOnClickListener.onClick(View.java:4725)
at android.view.View.performClick(View.java:5637)
at android.view.View$PerformClick.run(View.java:22429)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6121)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:889)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:779)
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Native Method)
at android.view.View$DeclaredOnClickListener.onClick(View.java:4720)
... 9 more
Caused by: java.lang.Exception: Exception at the end of the call
at ly.count.android.demo.a.b(SourceFile:29)
at ly.count.android.demo.a.a(SourceFile:21)
at ly.count.android.demo.ActivityExampleCrashReporting.c(SourceFile:98)
at ly.count.android.demo.ActivityExampleCrashReporting.b(SourceFile:94)
at ly.count.android.demo.ActivityExampleCrashReporting.a(SourceFile:90)
at ly.count.android.demo.ActivityExampleCrashReporting.onClickCrashReporting10(SourceFile:82)
... 11 more

iOS symbolication sample:

Sample iOS Symbolication input Sample iOS Symbolication output
libsystem_platform.dylib            0x00000001826c130c _sigtramp + 36
mahya                               0x000000010006e174 mahya + 156020
mahya                               0x000000010006d060 mahya + 151648
mahya                               0x000000010006ad34 mahya + 142644
UIKit                               0x0000000189925d74  + 184
UIKit                               0x00000001898eedb8  + 128
UIKit                               0x00000001898ff2b0  + 88
UIKit                               0x000000018a1c0ff8  + 272
UIKit                               0x0000000189b5e138  + 280
UIKit                               0x0000000189b5d96c  + 1064
UIKit                               0x0000000189b5d4c4  + 60
UIKit                               0x000000018a1c0ff8  + 272
UIKit                               0x0000000189b5d400  + 436
UIKit                               0x00000001898eea40  + 672
UIKit                               0x00000001898ee364  + 1780
UIKit                               0x00000001898ec954  + 228
UIKit                               0x00000001898eab04  + 3152
UIKit                               0x0000000189b74750  + 228
UIKit                               0x000000018975ea50  + 384
UIKit                               0x0000000189b74400  + 344
UIKit                               0x0000000189768fd4  + 2480
UIKit                               0x000000018976436c  + 3192
UIKit                               0x0000000189734f80  + 340
UIKit                               0x0000000189f2ea20  + 2400
UIKit                               0x0000000189f2917c  + 4268
UIKit                               0x0000000189f295a8  + 148
CoreFoundation                      0x00000001835b142c  + 24
CoreFoundation                      0x00000001835b0d9c  + 540
CoreFoundation                      0x00000001835ae9a8  + 744
CoreFoundation                      0x00000001834deda4 CFRunLoopRunSpecific + 424
GraphicsServices                    0x0000000184f49074 GSEventRunModal + 100
UIKit                               0x0000000189799c9c UIApplicationMain + 208
mahya                               0x000000010005fe14 mahya + 97812
libdyld.dylib                       0x00000001824ed59c  + 4

Configuring the server for symbolication

The first step to using symbolication is installing and enabling the symbolication plugin, which is called "Crash symbolication".

The next step to using symbolication is creating the connection to the Countly symbolication server. To do so, you will need a symbolication API key provided by Countly. The Countly symbolication server address is https://symbolication.count.ly. When you get your API key, you will need to set it in the server configuration screen under the "crashes" section.

After you have made sure that those fields contain valid information, press the "Test Connection" button to make sure everything is working correctly. If your provided server URL or API key is wrong or your Countly server can't reach the symbolication server, you may diagnose it with this button.

You should see these alert messages if everything is working correctly.

You should now be done setting up your Countly instance to use crash symbolication.

Preparing your app for symbolication

This section will guide you through the Android & iOS symbolication processes.

Android

Android's official tool for code shrinking and obfuscation is called ProGuard. A detailed description of its usage can be found here. There is also a paid tool with additional features called DexGuard. Both Proguard and Dexguard can be used for Countly crash symbolication. Currently, we do not support any other Android obfuscation libraries.

If you are using Android Studio for development, mapping files will not be produced when you make instant runs. For them to appear, you will either need to generate a signed APK or choose the "Build APK" option.

After the build is complete, the symbol file called mapping.txt can be found under <module-name>/build/outputs/mapping/release/ or <module-name>/build/outputs/mapping/debug/, depending on how you initiate the build process.

Proguard rules

You have the option of adding some rules to proguard/dexguard and modifying how it runs. These rules should be added in the "proguard-rules.pro" file.

If you are deciding to use proguard, you have to keep in mind that it will rename the function and class names. Therefore, it will break code that is using reflection if you don't take steps to safeguard from this happening. You may find more information on the proguard manual.

At the very least, you should include these lines in your proguard rule file:

-keep class org.openudid.** { *; }

-renamesourcefileattribute SourceFile
-keepattributes SourceFile,LineNumberTable

The first one is needed to prevent openudid from breaking, and Countly uses it for generating user IDs. The third and fourth are needed to add source file and line number information to your android stack traces.

The proguard rule file should be named "proguard-rules.pro", and it is usually located at the root of your module. More information here.

iOS

The symbol file is a dSYM file for iOS.

  • A dSYM file is Apple's standard Mach-o file which contains debug symbols for a given build.
  • It includes debug symbols for all architectures used for the build (e.g. armv7, arm64).
  • Its size may vary depending on the original source code and libraries used in the project.
  • It is actually a file-like folder structure, and actual dSYM data is in the binary file AppName.app.dSYM/Contents/Resources/DWARF/AppName.

dSYM Location:

First of all, for each executable target (main app, extensions, and Cocoa Touch Frameworks) in the project, a separate dSYM file is generated when the project is built. dSYM location depends on build settings. By default, it is defined by $DWARF_DSYM_FOLDER_PATH Xcode Environment Variable.

An example location is: ~/Library/Developer/Xcode/DerivedData/AppName-abcdef0123456789/Build/Products/Release-iphoneos/AppName.app.dSYM

In addition, if you use the Product > Archive option in Xcode to create .xcarchive of your app, you may find created dSYM inside .xcarchive. By default, its location is: ~/Library/Developer/Xcode/Archives/YYYY-MM-DD/AppName DD-MM-YYYY, HH.mm.xcarchive/dSYMs

Automatic dSYM Upload

For automatic dSYM, please see the Countly iOS SDK documentation:

https://support.count.ly/hc/en-us/articles/360037753511-iOS-watchOS-tvOS-macOS#symbolication

Using symbolication

This section will guide you when uploading a symbol file and then symbolicating your stack trace for Android and iOS.

Uploading the Symbol File

Now that the connection to the symbolication server is established and the necessary symbol files are procured, we can get to the symbolication of specific stack traces.

After enabling the crash symbolication plugin, you might have noticed that additional choices have been added to your crash sub-menu items:

"Overview" takes you to the usual crash overview. "Manage Symbols" takes you to a screen where you can manage all the symbol files uploaded for this application. "Symbolication logs" is similar to the request logs, where a short history of your symbolication requests is kept. You would visit that screen only if there are some problems with symbolication process.

To upload a symbol file, open the "Manage symbols" section. At first it will look empty, as shown below:

There you will have to click on the "Add Symbolication File" button. In the side dialog, select the type, add the build ID, mapping/symbol file, note, and click "Upload file". You will need to do this for every version of your app you would like to symbolicate.

Only one symbol file upload required

You should only upload one symbol file per application version. Multiple symbol file uploads are not supported.

In the Type selection, you need to choose the platform for the symbol file you are uploading.

For Android, the Build ID field is the version name. For iOS, the Build UUID field is your app's Build UUIDs.

You can get Build UUIDs using the dwarfdump --uuid command on the dSYM file, and you may specify more than one Build UUID, comma-separated, for each architecture.

Example:

erkanmbp:Desktop erkanyildiz$ dwarfdump --uuid CountlyTestApp-iOS.app.dSYM
UUID: AD4F5647-B2A0-3D85-8DF4-78D4DFD83296 (armv7) CountlyTestApp-iOS.app.dSYM/Contents/Resources/DWARF/CountlyTestApp-iOS
UUID: 70B0DE66-D337-3952-914D-A1E542667E20 (arm64) CountlyTestApp-iOS.app.dSYM/Contents/Resources/DWARF/CountlyTestApp-iOS

While choosing a Symbolication/Mapping File upon uploading the page for iOS , please do not forget to zip the dSYM file before uploading. Otherwise, you will not be able to upload a dSYM file in a folder structure.

The "Notes" field is optional.

When everything is filled out, simply click "Upload file".

Note that the Android Build ID and iOS Build UUID specified here must match your app's Build ID or Build UUID.

You should do this step for every version/build you would like to symbolicate.

Symbolicating a Crash

After some time has passed, you will start to see new exceptions in your crash overview pane. If you have uploaded correct symbols for those versions, then you are ready to move forward with the symbolication process.

To symbolicate a crash, you first have to go to its detailed view by clicking on "view".

The detailed crash view may be divided in two parts. The top contains the crash group stack trace and the bottom contains entries for each specific crash and its circumstances.

When clicking on a specific crash entry, it opens up additional information which also contains a "Symbolicate" button, assuming it's possible to symbolicate the crash (e.g. symbol file is uploaded for corresponding version). At the top of the crash group section, you may also see the "Symbolicate" button.

When you click on the "Symbolicate" button, you should see the "Symbolication in progress" message. When that process is complete, you should be able to see the symbolicated stack trace.

In the current symbolication implementation there are some technical limitations, and the top crash group will show a "symbolicate" button only after a crash from a newer app version is received. Therefore, if you would like to symbolicate crashes from a version you had before you enabled crash symbolication, you will have to go down to a specific crash entry at the bottom of the detailed crash view.

Diagnosing a problem

You might come across a situation when trying to symbolicate a crash, where you will see something similar to the following:

This means there was a problem while trying to symbolicate your crash. To get more information on the problem, either click on the red text or open the "Symbolication Logs" section.

After the issue which caused the failure has been fixed, you may rerun that symbolication task.

Was this article helpful?
0 out of 0 found this helpful

Looking for help?