macOSクラッシュレポートの読み方 – Macアプリの不具合を切り分けるトラブルシューティングガイド

Macでアプリがクラッシュすることは、実はそれほど多くありません。しかし、いざ発生すると、その原因を突き止めたくなるものです。特に開発者であれば、自分のアプリがなぜクラッシュするのかを把握することは不可欠です。この記事では、macOSのクラッシュレポートを読み解き、難解な専門用語を整理する方法をわかりやすく解説します。

クラッシュレポートを開く方法

Mac上でアプリがクラッシュすると、自動的にクラッシュレポートが生成されます。クラッシュ直後には「[アプリ名]が予期しない理由で終了しました」という警告ダイアログが表示され、「レポート…」ボタンをクリックすればその場で内容を確認できます。また、クラッシュレポートは「コンソール(Console)」アプリからもいつでも閲覧可能です。

1. Spotlightに「コンソール」と入力するか、「アプリケーション → ユーティリティ → コンソール.app」からコンソールアプリを起動します。

2. 左側のメニューで「ユーザーレポート」をクリックし、表示したいクラッシュレポートを選択します。ファイル名はすべて「.crash」で終わり、タイトルに日付とクラッシュしたアプリ名が含まれています。クラッシュレポートの詳細は右側のペインに表示されます。

macOSクラッシュレポートの読み方

ここからは、クラッシュレポートを上から順に読み解いていきましょう。

何がクラッシュしたのか?

クラッシュレポートの最初の部分には、どの「プロセス」またはアプリケーションがクラッシュしたかが記載されています。一般的なトラブルシューティングで最も重要なのはプロセス名です。

Process: aText [11473]
Path: /Applications/aText.app/Contents/MacOS/aText
Identifier: com.trankynam.aText
Version: 2.19 (62)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: aText [11473]
User ID: 501

いつクラッシュしたのか?

次の部分には、クラッシュが発生した日時が記録されています。あわせてシステムに関する基本情報も確認できます。

Date/Time: 2018-03-15 00:58:10.552 -0400
OS Version: Mac OS X 10.12.6 (16G1036)
Report Version: 12
Anonymous UUID: 6C985CFD-6975-3F30-50EB-0713315F5090
 
Time Awake Since Boot: 630000 seconds
 
System Integrity Protection: enabled

何が原因でクラッシュしたのか?

このセクションが最も重要な情報源となります。アプリケーションが出力する「例外タイプ(Exception Type)」から、クラッシュの原因を読み取ることができます。ログには、どのスレッドがクラッシュしたかも記録されています(この例ではスレッド0)。

Crashed Thread: 0 Dispatch queue: com.apple.main-thread
 
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000040dedeadbec0
Exception Note: EXC_CORPSE_NOTIFY
 
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

Appleは技術ドキュメントの中で、代表的な例外タイプをいくつか挙げています。

• 不正なメモリアクセス(EXC_BAD_ACCESS / SIGSEGV / SIGBUS) – プログラムが誤った方法、または無効なアドレスでメモリにアクセスしようとした場合に発生します。メモリの問題を説明するコードが付加されます。
• 異常終了(EXC_CRASH / SIGABRT) – 異常な終了。通常は捕捉されなかったC++例外やabort()の呼び出しによって引き起こされます。
• トレーストラップ(EXC_BREAKPOINT / SIGTRAP) – SIGABRTに似ていますが、こちらはデバッガがブレークポイントで処理を中断し、エラーを追跡できるように設計されています。
• 不正な命令(EXC_BAD_INSTRUCTION / SIGILL) – プロセスが理解できない、または処理できない命令を発行した場合に発生します。
• 終了(SIGQUIT) – 十分な権限を持つ別のプロセスによって強制終了された場合。通常は監視プロセス(watchdog)が異常動作するプロセスを終了させます。
• 強制終了(SIGKILL) – システムの要求によりプロセスが終了された場合。例外の説明として終了コードが付加されます。

今回のクラッシュレポートからわかるように、アプリケーションはマップされていないメモリ領域へアクセスしようとしました。これはアプリ側のプログラミングミスか、特殊なユーザー状態によってアプリがメモリを正しくマップできなかったことが原因と考えられます。

クラッシュに至った経緯は?

その後には、クラッシュに至るまでの一連の出来事が新しい順(逆時系列)にリスト表示されます。これらはスレッドごとに分類され、スレッド0から始まります。

このレポートには4つの列があります。1列目はイベント番号(0から始まる逆時系列)、2列目はプロセスの識別子、3列目はメモリ内のプロセスのアドレス、4列目はプログラムのタスク名です。

この「バックトレース(backtrace)」は一見すると分かりにくいものです。「シンボリケート(symbolicated)」されているため、一部のメモリアドレスは関数名やアプリケーションのタスク名に置き換えられています。ただし、完全にシンボリケートできないこともあり、その場合は判読不能なメモリアドレスがレポート中に散在することになります。

先ほどのクラッシュレポートでも、com.trankynam.aTextはシンボリケートされていないのがわかります。完全にシンボリケートされていても、バックトレースを読み解くのは容易ではありません。開発者によっては、アプリのタスクやイベントについて有益な注釈を残していることもありますが、多くの場合は暗号のような名称や数値コードの羅列です。シンボリケーションを読み解ければ状況を把握できるかもしれませんが、バックトレースを完全に理解するには、自分でそのアプリのコードを書いた人でなければならないこともあります。

まとめ:クラッシュレポートは役立つのか?

開発者にとって、クラッシュレポートを読むことは必須のスキルです。アプリのどの部分が、なぜクラッシュしているのかを正確に把握できます。一方、一般ユーザーにとってはそこまで有用ではありません。しかし、繰り返し発生するクラッシュに悩まされているなら、クラッシュレポートは問題の切り分けや、開発者との連携による修正に大いに役立ちます。検索の手がかりとなるエラーコードが得られたり、テクニカルサポートに正確な情報を提供したりできるでしょう。さらに詳しい技術情報が必要な方は、Appleが公開しているクラッシュに関するテクニカルノートを参照してください。