通常、Mac でアプリがクラッシュすることは非常にまれです。しかし、実際に問題が発生した場合は、これらの問題を追跡する必要があるかもしれません。また、あなたが開発者であれば、アプリがクラッシュする理由を理解する必要があります。ここでは、macOS でコード化された言語ごとにクラッシュ レポートを読んで並べ替える方法を説明します。
クイックリンク
クラッシュレポートを開く
Mac でアプリケーションがクラッシュすると、クラッシュ レポートが自動的に生成されます。これはクラッシュ後に表示され、「[アプリケーション] が予期せず停止しました。」という警告ダイアログ ボックスが表示されます。このクラッシュ レポートは、[レポート…] ボタンをクリックすると、このウィンドウですぐに読むことができます。クラッシュ レポートはコンソール アプリにもあります。
1. Spotlight で「Console」と入力するか、「Application -> Utilities -> Console.app」に移動して、コンソール アプリを開きます。
2. 左側のメニューの「ユーザーレポート」をクリックし、表示したいクラッシュレポートをクリックします。これらのファイルはすべて「.crash」で終わり、タイトルに日付とクラッシュしたアプリケーションが含まれています。クラッシュ レポートの詳細は、右側のペインに表示されます。
Mac OS クラッシュ レポートを読む
クラッシュ レポートを上から下まで見てみましょう。
何が壊れているのですか？
クラッシュ レポートの最初の部分では、プロセスまたはアプリケーションが「壊れた」かどうかがわかります。トラブルシューティングにとって最も重要な部分はプロセス名です。
プロセス: aText [11473] パス: /Applications/aText.app/Contents/MacOS/aText 識別子: com.trankynam.aText バージョン: 2.19 (62) コードタイプ: X86-64 (ネイティブ) 親プロセス: ??? [1] 責任者: aText [11473] ユーザーID: 501
いつ誤動作が発生しましたか?
2 番目の部分では、障害がいつ発生したかがわかります。また、システムに関するちょっとした情報も提供されます。
日付/時刻: 2018-03-15 00:58:10.552 -0400 OSバージョン: Mac OS 630000秒 システム整合性保護: 有効
何が原因で故障したのでしょうか？
次の部分が最もライトアップされます。アプリケーションがスローする「例外の種類」から、クラッシュの原因がわかります。また、クラッシュしたスレッド (この場合はスレッド 0) をログに記録して報告します。
クラッシュしたスレッド: 0 ディスパッチ キュー: com.apple.main-thread 例外の種類: EXC_BAD_ACCESS (SIGSEGV) 例外コード: KERN_INVALID_ADDRESS at 0x000040dedeadbec0 例外の注意: EXC_CORPSE_NOTIFY 終了シグナル: セグメンテーション違反: 11 終了理由: 名前空間 SIGNAL、コード 0xb 終了プロセス: exc handler [0]
アップルのリスト いくつかの一般的なタイプの例外 その技術文書には次のように記載されています。
不正なメモリ アクセス (EXC_BAD_ACCESS / SIGSEGV / SIGBUS) – プログラムがメモリに不正にアクセスしようとしているか、無効なアドレスを使用しています。メモリの問題を説明するコード付き。
異常終了 (EXC_CRASH/SIGABRT) – 異常終了。通常はキャッチされなかった C++ 例外と abort() の呼び出しによるものです。
トレース トラップ (EXC_BREAKPOINT / SIGTRAP) – SIGABRT と同じですが、この終了により、接続されたデバッガにブレークポイントでプロセスを中断し、エラーを追跡する機会が与えられます。
不正な命令 (EXC_BAD_INSTRUCTION / SIGILL) – 処理が理解できない、または処理できなかった処理を発行しました。
終了 (SIGQUIT) – プロセスは、十分な権限を持つ別のプロセスによって終了されました。通常、監視プロセスにより不正行為は停止されます。
TERMINATE (SIGKILL) – プロセスはシステムの要求により終了されました。例外を説明するために終了コードが追加されます。
クラッシュ レポートからわかるように、アプリケーションは隔離されていないメモリにアクセスしようとしました。これは、アプリケーションのプログラミング エラー、またはアプリケーションがメモリを正しくマップしない異常なユーザー条件が原因です。
故障の原因は何ですか?
次に、クラッシュの原因を時系列に沿って逆順に並べたリストを見ていきます。これらはスレッド 0 から順にスレッドごとにソートされます。
このレポートには 0 つの列があります。最初のレポートは、イベント番号を XNUMX から始まる新しい順にレポートします。XNUMX 番目のレポートはプロセス ID です。 XNUMX 番目はメモリ内のプロセスのアドレスです。 XNUMX 番目はプログラムのタスクの名前です。
この「回帰」はやや混乱を招く可能性があります。これは「記号的」であり、一部のメモリ アドレスが関数またはアプリケーション タスクの名前に置き換えられていることを意味します。場合によっては、これを完全に行うことができず、読み取り不能なメモリ アドレスがレポート全体に散在したままになります。
上記のクラッシュ レポートでは、com.trankynam.aText が非シンボリックであることがわかります。完全にエンコードしても、バックエンドを読み取るのが難しい場合があります。ソフトウェア開発者は、アプリケーションのタスクやイベントに関する役立つメモを含めることがあります。また、暗号化されたアドレスまたはデジタル コードである場合もあります。この象徴性を理解できれば、何が起こっているのかを理解できるかもしれません。ただし、バックトレースを理解するには、できる限りアプリケーションを自分でコーディングする必要があります。
結論: これは役に立ちますか?
ソフトウェア開発者であれば、クラッシュ レポートを読むことが不可欠です。これは、アプリケーションのどの部分が問題を引き起こしているのか、またその理由を理解するのに役立ちます。あなたがユーザーであれば、それらは役に立ちません。ただし、クラッシュが継続的に発生する場合、クラッシュ レポートは問題のトラブルシューティングや、開発者と協力して問題を解決するのに役立ちます。 Google を通じてエラー コードを適切に解決してもらうことも、正しい情報をテクニカル サポートに提供することもできます。抜本的な詳細が必要な場合は、次の URL ですべてを読むことができます。 クラッシュに関する Apple テクニカル ノート.
