前提条件
- Vegaアプリから生成されたクラッシュファイル（.acr）が必要です。
- アプリのクラッシュレポートをシンボリケートする方法を読んで、ACRファイルとそのデータについて理解します。
ACRファイルと概要レポートについて
ACRファイルと概要レポートは同じファイルではなく、それぞれ別々の目的で使用されます。概要の使用方法
Vega Studioは、シンボリケーションが完了すると、自動的に概要を新しいタブとして開きます。 クラッシュを診断するには、次の手順に従います。- クラッシュしたメタデータを検査します。 最初にMetadataを確認する - クラッシュの理由と言語を確認して、発生したクラッシュのタイプを理解します。
- スタックトレースでアプリ関数を検索します。 Symbolicated Stacktracesを調べる - スタックトレースで、アプリに由来する関数名を探します。
- クラッシュ時のメモリ使用量を確認します。 System Infoを確認する - クラッシュ時のメモリ使用量を確認します。
- ソースコードと相互に参照する - スタックトレースのファイルパスと行番号を使用して、プロジェクト内の問題のあるコードを特定します。
-
次の手順を決定する
- クラッシュがアプリコードで発生した場合は、問題を修正してテストします。
- クラッシュがOSコードで発生した場合や、システムフレームしか表示されない場合は、ACRファイルを添えてAmazonサポートに問い合わせます。
- よくわからない場合は、クラッシュの発生元の分析をガイダンスとして参照してください。
- シンボリケーションに失敗した場合や、概要が不完全な場合は、クラッシュ分析に関する問題の修正を参照してください。
概要の構造
以下のセクションでは、概要の構成要素と、それぞれに含まれる情報について説明します。ファイルヘッダー
ACRファイルのファイルパスと、関連する一時作業ディレクトリのパスが含まれます。これらのパスを使用して、元のクラッシュファイルとシンボリケーションの中間ファイルを特定できます。 例：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のスタックトレースのみが表示されます。
- ネイティブクラッシュ：デフォルトでは、ネイティブスタックトレースのみが表示されます。
スタックフレームの解読
「スタックトレース」は、クラッシュを引き起こした一連の関数呼び出しを示します。トレースの各行は「スタックフレーム」と呼ばれます。 ネイティブスタックフレームには、フレーム番号、メモリアドレス、ライブラリ名が含まれます。デバッグシンボルがある場合は、フレームに関数名、ソースファイル、行番号も表示されます。スタックトレースの??について
ネイティブスタックフレームに??が表示される場合は、そのメモリアドレスに位置する関数名をシンボリケーションツールで解決できなかったことを示します。つまり、その位置にはデバッグシンボルがありません。隣接するスタックフレームのコンテキストを調べることで、それがアプリコードに該当するか、OSレベル／システムのライブラリコードに該当するかを判断できます。
??のあるフレームは、アプリ内のバグではありません。これらは、エクスポートされたデバッグシンボルなしで動作するシステムコードを表します。アプリのファイルパスと関数名が表示されているフレームを重点的に確認してください。
クラッシュの発生元がアプリのコードとAmazonのコードのどちらにあるかを判断するには、アプリがクラッシュする原因を検出する方法を参照してください。
ローメモリキラー（LMK）クラッシュ
LMKクラッシュでは、プロセスの内部でクラッシュが発生するのではなく、OSによって外部からプロセスが強制終了されるため、スタックトレースは生成されません。これらのクラッシュでは、CRASH_REASONフィールドにLowMemoryKillerと表示されます。LowCPUKillerやLRUDepthMaintenanceなど、同じようにリソースマネージャーによって終了された場合もスタックトレースはありません。すべての一覧については、クラッシュの理由のリファレンスを参照してください。
シンボリケートされたスタックトレースのセクションが空で、クラッシュの理由がリソースマネージャーによる終了を示している場合は、次の手順に従います。
- スタックトレースのセクションをスキップします。
- System Infoでメモリ圧迫データを確認します。メモリ消費量の多い上位5つのプロセスと、圧迫情報の統計を調べます。
- メモリ消費量の多い上位のプロセスにアプリが含まれている場合は、コード内にメモリリーク、大量の画像バッファー、キャッシュの過剰使用がないかどうかを調査します。
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ファイルに記録されたシステム情報が表示されます。次の情報が含まれます。- セクションから、メモリ消費量の多い上位5つのプロセス 例：アプリが250MBを使用していて上位5つに含まれる場合、メモリの圧迫が要因となっている可能性があります。
- セクションから、圧迫情報の統計 例：メモリの圧迫値が高い場合、システムで使用可能なメモリが不足していたことを示します。
Native stacktrace - all threads
このセクションには、すべてのスレッドのネイティブスタックトレースが表示されます。このトレースは、対話型のGDBセッションでthread apply all btを実行することで生成できます。
