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のいずれかです。

クラッシュの理由のリファレンス

次の表は、CRASH_REASONフィールドに表示されるクラッシュの理由と、その終了をトリガーしたもの、ACRファイルにミニダンプとスタックトレースが含まれているかどうかを示す一覧です。

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によって外部からプロセスが強制終了されるため、スタックトレースは生成されません。これらのクラッシュでは、CRASH_REASONフィールドにLowMemoryKillerと表示されます。LowCPUKillerやLRUDepthMaintenanceなど、同じようにリソースマネージャーによって終了された場合もスタックトレースはありません。すべての一覧については、クラッシュの理由のリファレンスを参照してください。

シンボリケートされたスタックトレースのセクションが空で、クラッシュの理由がリソースマネージャーによる終了を示している場合は、次の手順に従います。

1. スタックトレースのセクションをスキップします。
2. System Infoでメモリ圧迫データを確認します。メモリ消費量の多い上位5つのプロセスと、圧迫情報の統計を調べます。
3. メモリ消費量の多い上位のプロセスにアプリが含まれている場合は、コード内にメモリリーク、大量の画像バッファー、キャッシュの過剰使用がないかどうかを調査します。

ReclaimMediaResourceクラッシュ

クラッシュの理由がReclaimMediaResourceの場合は、アプリがバックグラウンドに移行したときにネイティブのメディア再生リソース（メディアデコーダーやビデオサーフェスなど）を解放しなかったため、OSがアプリを終了したことを示します。OSは、これらのリソースを回収してほかのアプリに再利用します。

このクラッシュは、AppStateバックグラウンドハンドラーで、async/awaitを使用してリソースのクリーンアップを順次実行している場合に発生します。KeplerScriptランタイムは、バックグラウンドへの遷移後にJavaScriptスレッドを中断するため、awaitの後の処理は実行されない可能性があります。その結果、ネイティブのメディアリソースが解放されず、OSによってアプリが終了されます。

この問題を修正するには、AppStateバックグラウンドハンドラーで、非同期操作を行う前にネイティブのメディアリソースを同期的に開放します。詳細については、バックグラウンド／フォアグラウンド間でのアプリ状態の遷移を参照してください。

クラッシュの発生元の分析

ANR以外のクラッシュの場合、概要には、クラッシュがアプリコードとOSコードのどちらで発生したと考えられるかが示されます。シンボリケートされたスタックトレースがツールで分析され、クラッシュの発生元が特定されます。

• クラッシュがアプリレイヤーで発生したと考えられる場合： スタックトレースがアプリコードを参照しています。スタックトレースで詳細を確認してください。

  例： スタックトレースにMyApp.handleUserInput()やcom.example.myapp.MainActivity.onCreate()が表示される。

• クラッシュがOSレイヤーで発生したと考えられる場合： スタックトレースからアプリに関連するフレームが見つかりませんでした。Amazonサポートにお問い合わせください。

  例： スタックトレースに__libc_do_syscall()やbinder_call_internal()などのシステムコールだけが表示される。

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
- Crash possibly in the OS layer: The tool found no app-related frames in the stack trace.
- Reach out to Amazon for support.

### 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年6月18日