Finder が予期せず終了しました。しかし、なぜでしょうか?
クラッシュ レポートは、macOS でアプリがクラッシュした理由の手がかりにつながる可能性があります。これらのレポートがあなたの Mac について実際に何を言っているのかを理解する方法は次のとおりです。
アプリがMac で予期せず終了します。
プログラミングの世界では「クラッシュ」として知られているこれらのエラーは、通常、システムまたは CPU が実行できない不適切なコードが実行されたときに発生します。また、アプリが不足しているバージョンや古いバージョンのライブラリまたはフレームワークにアクセスしようとして、必要なコードを実行できない場合にも発生する可能性があります。
macOS でこれらのクラッシュ アラートのいずれかが表示されたら、[無視] ボタンをクリックするか、[レポート] ボタンをクリックします。
[レポート] ボタンをクリックすると、Finder はクラッシュ レポートのウィンドウと [Apple に送信] ボタンを表示します。エラーの原因が Apple ソフトウェアである場合は、Apple にレポートを送信する必要があります。
各クラッシュ レポートは、/Users/~/Library/Logs/のユーザー フォルダー内のフォルダー”DiagnosticReports”内の.ips ファイルに保存されます。
表示して開くこともできます。コンソール ウィンドウの左側にある [クラッシュ レポート] 項目を選択し、ウィンドウの右側にあるレポートを選択してから、レポートを Control キーを押しながらクリックするか右クリックして、Apple のコンソール アプリでこれらのレポートを選択します。ポップアップメニューから「Finderで表示」。
これにより、Finder で DiagnosticReports フォルダーが開き、保存されているすべてのクラッシュ レポート ファイルが表示されます。これらのレポートは、限られた時間だけ macOS によって保持され、その後、最も古いレポートから自動的に削除が開始されます。
選択したクラッシュ レポート ファイルをゴミ箱に移動する場合は、コンソールのポップアップ メニューに [ゴミ箱に移動] メニュー項目もあります。
Finder で.ips ファイルをダブルクリックすると、コンソール アプリでファイルが再び開かれるだけです。 Finder で.ips ファイルを Control キーを押しながらクリックし、ポップアップ メニューから [プログラムから開く] を選択してから [TextEdit] を選択すると、TextEdit で.ips ファイルを開くこともできます。
.ips ファイルに保存されている各レポートのテキストは JSON 形式であることに注意してくださいであるため、理解するには JSON を読み取れる必要があります。
コンソールでクラッシュ レポートを読む
コンソールでクラッシュ レポートを選択すると、下のメイン テキスト ペインでそのテキストを読むことができます
クラッシュ レポートの最初のいくつかのフィールドを見てみましょう. UNIX の「プロセス」は、実行中のアプリを意味します。フィールドは次のとおりです:
プロセス-アプリまたはプロセスの名前。パス-アプリ バイナリが存在するディスク上の場所。識別子-通常はバイナリまたはバンドル名ですが、常にではありません。バージョン-バイナリ バージョンまたは ???不明の場合。コード タイプ-Intel または Apple Silicon。両方の場合は「ユニバーサル」。親プロセス-このプロセスを起動したバイナリまたはアプリ。ユーザー ID-プロセスの UNIX ID または PID-ターミナルに表示されるのと同じプロセス ID。
次に、日付/時刻、OS バージョン、レポート バージョン、およびこのレポートの一意の UUID があります。固有のスリープ/ウェイク ID もあります。
レポートには、システム整合性保護が有効かどうかもリストされます。
次に、レポートにはクラッシュ自体の詳細がリストされます。この情報は非常に技術的なものである可能性があり、通常、アプリケーション コードで問題が発生した場所を追跡して修正できるようにするために、プログラマーまたは Apple を対象としています。
通常、クラッシュしたスレッド番号がリストされます。この場合、最初のスレッド-スレッド 0 です。スレッドは、他のコードから独立して実行されるコードのパスと考えてください。マルチコア CPU システムでは、必要に応じて、各コアに 1 つ以上のスレッドを実行させ、すべてのコアを並行して実行させることができます。これは、並列コンピューティングとして知られています。
次に、クラッシュまたは例外のタイプがリストされます:
例外タイプ: EXC_CRASH (SIGABRT)
この場合、SIGABRT-中止する UNIX シグナル、または殺す、スレッドが送信されました。シグナルは、UNIX が低レベルで実行中のプロセスに送信するメッセージで、実行中のプロセスに何かを行うように (この場合は終了するように) 指示します。
UNIX シグナルとその仕組みの詳細については、オンラインで入手できます。
次は、もしあれば例外コードですが、多くの場合ゼロです。
各コードの前の「0x」は、コード値が 16 進数または 10 進数ではなく「16 進数」であることを意味します。 16 進数は 16 を基数とする数値システムです。10 進数システムのように 10 ではなく 16 の値を使用します。 Hex は、追加の値として 0 ～ 9 を使用し、次に A ～ F を使用します。
16 進数システムがどのように機能するかについては、C プログラミング言語に関する優れた本を読むことができます。
次は終了理由です。これは通常、クラッシュの原因を示す英語のような説明です。この場合、「ネームスペース DYLD、コード 1 ライブラリがありません」。
DYLD はダイナミック ローダーです。これは、コードを実行する必要があるときに、コードをディスクからメモリに動的にロードする OS の一部です。 man dyld と入力して Return キーを押すと、ターミナルで DYLD の詳細を確認できます。
名前空間は、一部のプログラミング言語でコードのセクションを他のコードから分離するために使用される命名規則です。 「Code 1 Library missing」は、DYLD が動的にリンクされたライブラリを読み込もうとしたが、できなかったことを意味します。
プログラミングでは、ライブラリはコードのバンドルです。ライブラリは、静的 (ビルド時にアプリにリンクされる) または動的 (実行時にアプリに読み込まれる) のいずれかです。
エラーが DYLD ロード エラーである場合、次の行はそれがどのライブラリで、ディスク上のどこにあるかを示します:
“Library not loaded: @rpath/VBoxRT. dylib”
この場合、VBoxRT.dylib は Oracle の Virtual Box アプリケーション用の動的ライブラリ (.dylib) です。 DYLD は VBoxRT.dylib 動的ライブラリを探しましたが、見つからなかったためアプリを実行できず、終了するように SIGABRT シグナルが送信されました。
macOS および iOS 用のアプリは、実際には複数のコンポーネントで構成されています。通常はバンドルと呼ばれるフォルダーです。
この例では、Contents 内の MacOS フォルダー内にアプリのバイナリが表示されます。 app bundle 内のフォルダー:
Libraries フォルダーもあり、両方とも両方の Mac プラットフォーム アーキテクチャ用の.dylib 形式のフォルダー内の Apple Silicon および Intel x86 ライブラリ。これらは、DYLD の必要に応じて実行時にロードされます。
非常に単純なアプリ バンドルもあれば、非常に複雑なアプリ バンドルもあります。コードやその他のリソースは、アプリ バンドル以外の場所に保存できます。
上記の例では、.dylib が外部に保存され、通常は実行時に必要になったときにロードされます。.dylib は通常、バンドルではなく単一のバイナリです。
iOS および macOS では、コードやその他のリソースを含むバンドルであるフレームワークもサポートされています。上記のポップアップ メニューを使用してアプリ バンドル内を表示する場合と同じように、Finder でフレームワーク内を表示できます。フレームワークには、バンドル内に常にバージョン番号があります。
フレームワークは、アプリ バンドル内、または/Library/Frameworks と/user/~/Library/Frameworks に保存できます。 macOS と iOS 自体の多くは、動的にロード可能なフレームワークとして実装されています。
Apple は、macOS および iOS コードのロードおよびバインディング プロセスを詳細に説明する開発者向けフレームワーク プログラミング ガイドを用意しています。静的に関連する 2 つのコードを結合することは、バインディングではなくリンクと呼ばれ、コンパイラを使用してアプリケーションをビルドするときに行われます。
すべての静的コードが一度に読み込まれるため、より多くのシステム メモリが消費される可能性があります。
Apple には、Objective-C および Swift ランタイムの詳細を説明する別の開発者向けドキュメントもあります。どちらにも、アプリの実行中にコードがどのように読み込まれるかに関する追加情報が含まれています。
動的コードの読み込みは、1970 年代後半の SmallTalk などの言語にまでさかのぼります。 Apple のプラットフォームでは、Apple が 1997 年に NeXT を買収し、それに伴い、ダイナミック リンクと 内省。
NeXTStep Developer-最初の開発者パッケージの 1 つ動的バインディングを使用します。
今日、Apple ソフトウェアは依然として Objective-C または Apple 独自の Swift で作成されており、動的リンクとロードも使用しています。
動的読み込みでは、アプリのすべてのコードとリソースを一度にメモリに読み込む必要がないため、アプリのメモリ フットプリントを小さくすることができます。動的読み込みの欠点は、アプリの実行中にディスクからリソースを読み込む必要があるため、速度が遅くなる場合があることです。
これは、悪名高い macOS でビーチボール カーソルが回転する一般的な理由の 1 つです。
クラッシュ レポートの次に、「参照元:」の下にリストされている、問題のあるコードを呼び出した呼び出しプロセスまたはコード バイナリが通知されます。この場合、それはアプリのバンドル内に格納されたメインの VirtualBox アプリケーション バイナリでした。
英語で読める情報の最後の部分は「Reason:」です。これは、クラッシュが発生した理由を人が読める形で提供しようとします:
“‘/usr/lib/VBoxRT.dylib'(そのようなファイルはありません。dyld キャッシュにはありません)、(セキュリティ ポリシーでは @ パスの展開は許可されていません)
(起動時に終了、バックトレースを無視します)”.
これは、必要なライブラリがディスク上の/usr/lib/VBoxRT.dylib にあるはずだったが、そうではなかったことを意味します (通常、インストール時に VirtualBox インストーラーによってそこに配置されます)。DYLD は以前にロードされていませんでした。それ、そしてアプリは起動時に強制終了されました。
要約すると、上記の例では、VirtualBox が起動されましたが、必要な動的ライブラリが見つからなかったため、macOS によって強制終了され、終了しました。すべての情報が収集され、クラッシュ レポートに追加されました。
追加のコンソール情報とスタック トレース
クラッシュ レポートの残りの情報はさらに技術的なものであるため、ここでは詳しく説明しません、しかし、何が起こったのかを判断するためにすぐに読むことができるいくつかのことがあります.
特に、クラッシュが発生した理由の手がかりを探すために、アプリのコード実行を各スレッド番号の下に逆順にたどることができます。すべてがクラッシュするわけではなく、不足しているライブラリに関連しているため、アプリは正しく起動された可能性がありますが、クラッシュの原因となったコードのプログラミング エラーがあっただけです。
プログラマーは、存在しないシステム コードを呼び出したり、関数パラメーターを変更したりするという間違いを犯すことがあります。または、メモリアクセスエラー、またはコード内の変数を大量のデータで上書きしている可能性があり、通常はメモリ内の隣接する重要なものを上書きします。
これらのエラーはすべて、クラッシュを引き起こす可能性があります。
この情報は、通常、”理由:”セクションの直後にリストされ、通常、名前、メモリ内のアドレス、およびそれらがどのように読み込まれたかを含む、番号付きの関数呼び出しのリストがあります。このセクションでは、関数のリスト (スタック トレースと呼ばれます) を逆の順序で (下から上に) 読みたいことに注意してください。
関数が実際に実行される順序です。
この場合、必要なライブラリを起動時にロードできなかったため、スタックは非常に短く、ほとんどが DYLD の準備と停止/中止シグナルで構成されています。ただし、一部のエラーは非常に複雑なスタックを持つ場合があります。
通常、スタックの一番上 (最後) にある最後の関数が問題の原因ですが、常にではありません。
これを知っておくと、クラッシュの診断に役立ちます。失敗した正確な関数呼び出しをスタックが教えてくれるからです。次に、Apple の開発者向けドキュメントでその関数の名前を調べて、何が起こったのかについての手がかりを得ることができます。
クラッシュした関数を含むフレームワークまたはライブラリの名前がスタック トレースにリストされる場合があり、これによりさらに詳しい情報が得られます。
クラッシュ レポートのスタック ブロックの後には、スレッドの状態に関する情報が続きます。これは、開発者でない限り関係ありません。その後に、スレッドが実行されていた CPU、エラー コード (存在する場合) が続きます。およびトラップ番号。トラップは、何らかのイベントが発生したときに呼び出される OS コードの挿入ポイントです。
クラッシュ メモリと概要
次に、クラッシュに関係するバイナリ (コンパイルされたコード) に関する情報がいくつかあります。クラッシュ レポートの上部に記載されている情報と同じです。
その後、External Modification Summary (このプロセスと対話したプロセス ID の要約) と、コードのどの部分がメモリ内にあり、どの部分がまだディスク上にあるかに関する仮想メモリ (VM) 情報があります。仮想メモリとは、システムが使用できるメモリの合計を増やすために、OS が実際の RAM のように使用するディスク領域を指します。
次に、スタック、VM、リンクとテキスト セグメント、および DYLD と共有メモリに関する追加情報をまとめた「領域タイプ」情報があります。開発者でない限り、通常、この情報は無視できます。
各クラッシュ レポートの最後には、「完全なレポート」セクションがあります。これは基本的に、テキスト形式の.ips ファイル全体の生の完全な JSON ダンプです。生の JSON には、Apple Mac モデル ID、CPU タイプ、コード署名、その他の情報など、コンソール ウィンドウには表示されない追加情報が含まれています。
また、アプリには複数のスレッドが実行されている可能性があるため、上記のような概要がスレッドごとに表示されることに注意してください。ただし、通常、クラッシュしたスレッド番号はレポートの一番上に表示されるため、どのスレッド番号を見ればよいかがわかります。
初心者にとっては、これらすべてが圧倒されるように思えるかもしれませんが、クラッシュ レポートを読むコツをつかめば、通常は、何が起こったのか、そしてそれについて何かできるかどうかをすばやく簡単に把握できます。上記の例では、必要なライブラリが見つからないため、インストーラーを使用してアプリを単純に再インストールする必要があります。
Apple は詳細な Console User Guide をオンラインで提供しています。は非常に有益で役に立ちます。
