Prerequisites
- A crash file (.acr) from your Vega app
- Read Symbolicate App Crash Reports to familiarize yourself with ACR files and their data
Understanding ACR file and summary report
The ACR file and the summary report serve different purposes and aren’t the same file.How to use the summary
Vega Studio automatically opens the summary in a new tab once symbolication completes. To diagnose crashes:- Start with Metadata - Check the crash reason and language to understand what type of crash occurred.
- Examine Symbolicated Stacktraces - Look for function names from your app code in the stack trace.
- Review System Info - Check memory usage at crash time.
- Cross-reference with source code - Use the file paths and line numbers from the stack trace to locate the problematic code in your project.
-
Determine next steps:
- If the crash is in your app code, fix the issue and test
- If the crash is in OS code or you see only system frames, contact Amazon support with the ACR file
- If you’re unsure, see Crash source analysis for guidance
- If symbolication failed or the summary is incomplete, see Fix crash analysis issues
Summary structure
The following sections describe the components of the summary and what information each contains.File header
Contains the file path to the ACR file and the path to the related temporary working directory. Use these paths to find the original crash file and intermediate symbolication files. Example:Metadata
This section contains relevant metadata from the ACR file:- PROCESS - The process that crashed. Example:
com.example.myappor/usr/bin/eventmgrd - CRASH_REASON - The reason for the crash.
- CRASH_LANG - The programming language of the crashed code. Possible values: Native, JavaScript, or unknown. The ACR file reports “Unknown” in ANR cases when the crashing thread ID matches the JavaScript thread ID. The block can occur in either native or JavaScript code, so the tool can’t determine the language automatically.
- APP_VERSION - The app version that crashed. Example:
1.2.3or2024.11.15 - OS_BUILD_NUMBER - The OS build number from which the ACR file was generated. Example:
1001010003820 - BUILD_VARIANT - The build type from which the ACR file was generated. Possible values: user, userdebug, or user-external.
OS release file
Contains the contents of/etc/os-release collected by the ACR file. This information helps you verify the exact OS version and build configuration where the crash occurred, which is useful when reproducing issues or determining if a crash is OS-specific.
Symbolicated stacktraces
This section contains the decoded stack traces that show the exact location and sequence of function calls leading to the crash. The crash language determines which stack traces appear in this section:- JavaScript crashes: Only the JavaScript stack trace displays
- Native crashes: Only the native stack trace displays by default
Reading stack frames
A stack trace shows the sequence of function calls that led to the crash. Each line in the trace is a stack frame. Native stack frames include a frame number, a memory address, and a library name. If debug symbols are available, the frame also shows the function name, the source file, and the line number.Understanding ?? in stack traces
When you see ?? in a native stack frame, the symbolication tool couldn’t resolve the function name at that memory address. This typically indicates OS-level or system library code without available debug symbols.
?? aren’t a bug in your app. They represent system code that runs without exported debug symbols. Focus on frames that show your app’s file paths and function names.
To determine whether a crash originates from your code or Amazon’s code, see Detect Where the App Crash Originates.
Low Memory Killer (LMK) crashes
LMK crashes don’t produce a stack trace because the OS kills the process externally rather than the process crashing itself. If the symbolicated stacktraces section is empty and the CRASH_REASON indicates LMK, skip this section and check System Info for memory pressure data instead.System info
This section shows system information recorded in the ACR file at the time of the crash, including:- Top 5 memory-consuming processes from the section Example: If your app uses 250MB and appears in the top 5, memory pressure may be a factor
- Pressure info stats from the section Example: High memory pressure values indicate the system was low on available memory
Native stacktrace - all threads
This section shows the native stack trace for all threads. You can generate this trace by runningthread apply all bt in the interactive GDB session.
