Debug Crashes with ACR Summary

The aggregated crash report (ACR) summary organizes all crash debugging data into a single markdown file. Vega Studio generates the summary automatically at the end of every symbolication.

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:

1. Start with Metadata - Check the crash reason and language to understand what type of crash occurred.

2. Examine Symbolicated Stacktraces - Look for function names from your app code in the stack trace.

3. Review System Info - Check memory usage at crash time.

4. Cross-reference with source code - Use the file paths and line numbers from the stack trace to locate the problematic code in your project.

5. 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:

Path to ACR file: /Users/username/my-app-crash.acr
Path to acr_workdir: /Users/username/acr_workdir-a1b2c3d4

Metadata

This section contains relevant metadata from the ACR file:

• PROCESS - The process that crashed. Example: com.example.myapp or /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.3 or 2024.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.

#0  0xa1a701bc in VegaProjectTMTurboModule::VegaProjectTM::voidFunc (this=0xa1d99838) at /Users/developer_name/workspace/vega/testapp/VegaProjectTM/kepler/turbo-modules/VegaProjectTM.cpp:33

JavaScript stack frames include the function name, the source file, and the line number.

at onPress (node_modules/@amazon-devices/react-native-kepler/Libraries/Pressability/Pressability.js:587:18)

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.

#0 0xb6e01b26 in ?? () from /private/var/folders/_p/.../lib/libc.so.6

Frames with ?? 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 <meminfo> section

  Example: If your app uses 250MB and appears in the top 5, memory pressure may be a factor

• Pressure info stats from the <pressure_info> 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 running thread apply all bt in the interactive GDB session.

Example

Example of an unrendered ACR summary:

# ACR summary

Path to ACR file: [/Users/user/callie-test.acr](./crashfile)

Path to acr_workdir: /Users/user/acr_workdir-c4bcb13c

## Metadata

PROCESS: /usr/bin/eventmgrd
CRASH_REASON: SIGABRT
CRASH_LANG: Native
APP_VERSION: N/A
OS_BUILD_NUMBER: 1001010003820
BUILD_VARIANT: user
PRODUCT_NAME: callie
BUILD_FINGERPRINT: 4.0.137942.0(3072cab629675a74)/38N:user/release-keys
OE_VERSION: 4.0.0

## OS release file

NAME="OS"
OE_VERSION="4.0.0"
OS_MAJOR_VERSION="1"
OS_MINOR_VERSION="1"
RELEASE_ID="10"
OS_VERSION="1.1"
BRANCH_CODE="TV Ship"
BUILD_DESC="OS 1.1 (TV Ship/38)"
BUILD_FINGERPRINT="4.0.137942.0(3072cab629675a74)/38N:user/release-keys"
BUILD_VARIANT="user"
BUILD_TAGS="release-keys"
BUILD_DATE="Fri Jul 25 01:48:20 UTC 2025"
BUILD_TIMESTAMP="1753408100"
VERSION_NUMBER="1001010003820"

## Symbolicated stacktraces

### Native stacktrace

<details open>
<summary> Expand to see native stacktrace </summary>
<pre>
#0  __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
#1  0xb6877d98 in __GI___ioctl (fd=-4, request=3224396289) at ../sysdeps/unix/sysv/linux/ioctl.c:35
#2  0xb67544ba in binder_call_internal (runtime=0xf8a2c8, target=<optimized out>, code=<optimized out>, request=<optimized out>, response=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/runtimes/binder/direct/binder.c:1057
#3  0xb6754548 in binder_call (runtime=<optimized out>, target=<optimized out>, code=<optimized out>, request=<optimized out>, response=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/runtimes/binder/direct/binder.c:1082
#4  0xb6754d3c in ipcn_runtime_call (runtime=<optimized out>, remote_handle=<optimized out>, code=<optimized out>, request=<optimized out>, reply=reply@entry=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/runtimes/binder/direct/ipcn_runtime_binder.c:235
#5  0xb67569a6 in ipcn_call (runtime=0xf8a2c8, target=<optimized out>, code=<optimized out>, request=<optimized out>, reply=0xb2d32cd8) at /usr/src/debug/app-framework-neocoreipc/ssot-r0/app-framework-neocoreipc/cargo-project/api/core/ipcn_call.c:103
#6  0xb1be0418 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Troubleshooting

If you encounter issues with ACR analysis or symbolication, see Fix Crash Analysis Issues.

Related topics

• Symbolicate App Crash Reports
• Detect Where the App Crash Originates

Last updated: Feb 18, 2026