macOSクラッシュレポートを読んでMacのトラブルシューティングを行う方法

Macでのアプリのクラッシュは、一般的に非常にまれです。しかし、それらが発生した場合は、それらの原因を追跡することをお勧めします。また、開発者の場合は、アプリがクラッシュする理由を理解する必要があります。 macOSのクラッシュレポートを読み、不可解な言語で並べ替える方法は次のとおりです。

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

Macでアプリがクラッシュすると、クラッシュレポートが自動的に生成されます。クラッシュ後、「[アプリ]が予期せず終了しました。」という警告ダイアログが表示されます。 」そのクラッシュレポートは、「レポート…」ボタンをクリックすることにより、そのウィンドウですぐに読むことができます。クラッシュレポートは、コンソールアプリにもあります。

1. Spotlightに「Console」と入力するか、「Application->Utilities->Console.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

いつクラッシュしましたか？

2番目の部分は、クラッシュがいつ発生したかを示しています。また、システムに関する簡単な情報も提供します。

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

クラッシュの原因は何ですか？

次の部分は最も明るいです。アプリケーションによって提供される「例外タイプ」は、クラッシュの原因を示します。ログには、クラッシュしたスレッド（この場合はスレッド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 ）–プロセスは、十分な権限を持つ別のプロセスによって終了されました。通常、ウォッチドッグプロセスは、不正なプロセスを終了します。
• 殺された（SIGKILL ）–システムの要求によりプロセスが終了しました。例外を説明するために終了コードが追加されます。

クラッシュレポートからわかるように、アプリケーションはマップされていないメモリにアクセスしようとしました。これは、アプリケーションのプログラミングエラー、またはアプリケーションがメモリを正しくマップしない原因となる異常なユーザー状態が原因です。

クラッシュの原因は何ですか？

その後、クラッシュに至るまでの逆の時系列リストが表示されます。これらは、スレッド0から始まるスレッドでソートされます。

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

この「バックトレース」はやや困惑する可能性があります。これは「シンボリック」です。つまり、一部のメモリアドレスが関数名またはアプリケーションタスクに置き換えられています。これを完全に実行できない場合があり、読み取り不可能なメモリアドレスがレポート全体に散らばっています。

上記のクラッシュレポートでこれを確認できます：com.trankynam.aText 象徴されていません。完全な記号化があっても、バックトレースを読み取るのは難しい場合があります。開発者は、アプリケーションのタスクやイベントに関する有用なメモを含めることがあります。また、不可解なタイトルや数値コードである場合もあります。象徴を理解できれば、何が起こっているのかを理解できるかもしれません。ただし、バックトレースを理解するために、アプリケーションを自分でコーディングする必要がある可能性もあります。

結論：これは役に立ちますか？

開発者の場合、クラッシュレポートを読むことが不可欠です。アプリケーションのどの部分がクラッシュしているのか、そしてその理由を理解するのに役立ちます。あなたがユーザーの場合、彼らはそれほど役に立ちません。ただし、クラッシュが続く場合は、クラッシュレポートを使用すると、問題のトラブルシューティングを行ったり、開発者と協力して問題を修正したりできます。 Googleに役立つエラーコードを受け取ったり、適切な情報をテクニカルサポートに提供したりできる場合があります。厄介な詳細が必要な場合は、クラッシュに関するAppleのテクニカルノートですべてを読むことができます。