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. See Crash reason reference for a complete list of crash reasons and their descriptions.
- 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 that generated the ACR file. Example:
1001010003820 - BUILD_VARIANT - The build type that generated the ACR file. Possible values: user, userdebug, or user-external.
Crash reason reference
The following table lists the crash reasons you may see in theCRASH_REASON field, what triggered the termination, and whether the ACR file includes a minidump and stack trace.
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 means debug symbols aren’t available for that location. By examining the context of the adjacent stack frames, you can determine whether this corresponds to app code or OS-level/system library code.
?? 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. TheCRASH_REASON field shows LowMemoryKiller for these crashes. Related Resource Manager terminations like LowCPUKiller and LRUDepthMaintenance also lack stack traces—see the Crash reason reference for the full list.
If the symbolicated stacktraces section is empty and the crash reason indicates a Resource Manager termination:
- Skip the stacktraces section.
- Check System Info for memory pressure data—look at the top 5 memory-consuming processes and pressure info stats.
- If your app appears in the top memory consumers, investigate potential memory leaks, large image buffers, or excessive caching in your code.
ReclaimMediaResource crashes
AReclaimMediaResource crash reason indicates the OS terminated your app because it didn’t release native media playback resources (such as media decoders or video surfaces) when sent to the background. The OS reclaims these resources for other apps.
This crash occurs when your AppState background handler uses async/await to sequence resource cleanup. The KeplerScript runtime suspends the JavaScript thread after the background transition, so any work after an await may never execute. As a result, native media resources aren’t released and the OS terminates the app.
To fix this issue, release native media resources synchronously in your AppState background handler before any async operations. For details, see Transition App State between Background and Foreground.
Crash source analysis
For non-ANR crashes, the summary indicates whether the crash likely originated from app code or OS code. The tool analyzes the symbolicated stack traces to determine the crash source:-
Crash possibly in the app layer: The stack trace references app code. Review the stack trace for details.
Example: Stack trace shows
MyApp.handleUserInput()orcom.example.myapp.MainActivity.onCreate() -
Crash possibly in the OS layer: The tool found no app-related frames in the stack trace. Contact Amazon support.
Example: Stack trace shows only system calls like
__libc_do_syscall()orbinder_call_internal()
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.
