ACR summaryを使用してクラッシュをデバッグする方法

集約クラッシュレポート（ACR）の概要は、すべてのクラッシュデバッグデータを1つのマークダウンファイルにまとめたものです。Vega Studioは、シンボリケーションの最後に毎回、自動的に概要を生成します。

前提条件

• Vegaアプリから生成されたクラッシュファイル（.acr）が必要です。
• アプリのクラッシュレポートをシンボリケートする方法を読んで、ACRファイルとそのデータについて理解します。

ACRファイルと概要レポートについて

ACRファイルと概要レポートは同じファイルではなく、それぞれ別々の目的で使用されます。

概要の使用方法

Vega Studioは、シンボリケーションが完了すると、自動的に概要を新しいタブとして開きます。

クラッシュを診断するには、次の手順に従います。

1. 最初にMetadataを確認する - クラッシュの理由と言語を確認して、発生したクラッシュのタイプを理解します。

2. Symbolicated Stacktracesを調べる - スタックトレースで、アプリに由来する関数名を探します。

3. System Infoを確認する - クラッシュ時のメモリ使用量を確認します。

4. ソースコードと相互に参照する - スタックトレースのファイルパスと行番号を使用して、プロジェクト内の問題のあるコードを特定します。

5. 次の手順を決定する

   • クラッシュがアプリコードで発生した場合は、問題を修正してテストします。
   • クラッシュがOSコードで発生した場合や、システムフレームしか表示されない場合は、ACRファイルを添えてAmazonサポートに問い合わせます。
   • よくわからない場合は、クラッシュの発生元の分析をガイダンスとして参照してください。
   • シンボリケーションに失敗した場合や、概要が不完全な場合は、クラッシュ分析に関する問題の修正を参照してください。

概要の構造

以下のセクションでは、概要の構成要素と、それぞれに含まれる情報について説明します。

ファイルヘッダー

ACRファイルのファイルパスと、関連する一時作業ディレクトリのパスが含まれます。これらのパスを使用して、元のクラッシュファイルとシンボリケーションの中間ファイルを特定できます。

例：

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

Metadata

このセクションには、ACRファイルから関連するMetadataが含まれます。

• PROCESS - クラッシュしたプロセス。例：com.example.myappまたは/usr/bin/eventmgrd

• CRASH_REASON - クラッシュの理由。

• CRASH_LANG - クラッシュしたコードのプログラミング言語。報告される値は、 Native、JavaScript、unknownのいずれかです。ANRのケースでは、クラッシュしたスレッドIDがJavaScriptスレッドIDに一致する場合、ACRファイルには「Unknown」として報告されます。ブロックはネイティブコードとJavaScriptコードのどちらでも発生する可能性があるため、ツールで自動的に言語を判断することはできません。

• APP_VERSION - クラッシュしたアプリのバージョン。例： 1.2.3または2024.11.15

• OS_BUILD_NUMBER - ACRファイルが生成されたOSのビルド番号。例： 1001010003820

• BUILD_VARIANT - ACRファイルが生成されたビルドのタイプ。報告される値は、user、userdebug、user-externalのいずれかです。

OS release file

ACRファイルによって収集された/etc/os-releaseの内容が含まれています。この情報を使用して、クラッシュが発生した正確なOSバージョンとビルド構成を確認できます。これは、問題を再現したり、クラッシュがOS固有の問題かどうかを判断したりする場合に役立ちます。

Symbolicated stacktraces

このセクションには、クラッシュの原因となった関数呼び出しの正確な位置とシーケンスを示すデコードされたスタックトレースが含まれます。

このセクションに表示されるスタックトレースは、クラッシュが発生した言語によって決まります。

• JavaScriptのクラッシュ： JavaScriptのスタックトレースのみが表示されます。

• ネイティブクラッシュ： デフォルトでは、ネイティブスタックトレースのみが表示されます。

スタックフレームの解読

「スタックトレース」は、クラッシュを引き起こした一連の関数呼び出しを示します。トレースの各行は「スタックフレーム」と呼ばれます。

ネイティブスタックフレームには、フレーム番号、メモリアドレス、ライブラリ名が含まれます。デバッグシンボルがある場合は、フレームに関数名、ソースファイル、行番号も表示されます。

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

JavaScriptスタックフレームには、関数名、ソースファイル、行番号が含まれます。

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

スタックトレースの??について

スタックフレームに??が表示される場合は、そのメモリアドレスに位置する関数名をシンボリケーションツールで解決できなかったことを示します。これは通常、デバッグシンボルのないOSレベルのコードまたはシステムライブラリのコードです。

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

??のあるフレームは、アプリ内のバグではありません。これらは、エクスポートされたデバッグシンボルなしで動作するシステムコードを表します。アプリのファイルパスと関数名が表示されているフレームを重点的に確認してください。

クラッシュの発生元がアプリのコードとAmazonのコードのどちらにあるかを判断するには、アプリがクラッシュする原因を検出する方法を参照してください。

ローメモリキラー（LMK）クラッシュ

LMKクラッシュでは、プロセスの内部でクラッシュが発生するのではなく、OSによって外部からプロセスが強制終了されるため、スタックトレースは生成されません。Symbolicated stacktracesセクションが空で、CRASH_REASONがLMKを示している場合は、このセクションをスキップし、代わりにSystem Infoでメモリの圧迫データを確認してください。

System info

このセクションには、クラッシュ時にACRファイルに記録されたシステム情報が表示されます。次の情報が含まれます。

• <meminfo>セクションから、メモリ消費量の多い上位5つのプロセス

  例： アプリが250MBを使用していて上位5つに含まれる場合、メモリの圧迫が要因となっている可能性があります。

• <pressure_info>セクションから、圧迫情報の統計

  例： メモリの圧迫値が高い場合、システムで使用可能なメモリが不足していたことを示します。

Native stacktrace - all threads

このセクションには、すべてのスレッドのネイティブスタックトレースが表示されます。このトレースは、対話型のGDBセッションでthread apply all btを実行することで生成できます。

例

以下は、レンダリングされていない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?)

トラブルシューティング

ACR分析やシンボリケーションで問題が発生した場合は、クラッシュ分析に関する問題の修正を参照してください。

関連トピック

• アプリのクラッシュレポートをシンボリケートする方法
• アプリがクラッシュする原因を検出する方法

Last updated: 2026年2月18日