サーチ…
クラッシュに関する情報の検索
アプリケーションがクラッシュすると、Xcodeはデバッガに入り、クラッシュに関する詳細情報を表示します:
最も重要な部分は次のとおりです。
赤い矢印
赤い矢印は、どのコード行がクラッシュしたのか、なぜクラッシュしたのかを示しています。
デバッガコンソール
多くのクラッシュはデバッガコンソールに詳細情報を記録します。アプリがクラッシュしたときに自動的に表示されるはずですが、表示されていない場合は、 Xcodeの右上隅にあるボタンをクリックして、コンソールを表示します。 デバッガの右下にあるボタンをクリックします。
スタックトレース
スタックトレースは、プログラムがクラッシュしたコードに到達する前の関数をリストします。
スタックトレースの一部は、画面左側のデバッグナビゲータに表示され、デバッガコントロールを使用すると、デバッガで表示するスタックフレームを選択できます。
デバッガの(lldb)
プロンプトでbt
コマンドを入力してreturnキーを押すと、コピーして貼り付けることができるスタックトレースがテキスト形式で表示されます。
(lldb) bt
* thread #1: tid = 0x3aaec5, 0x00007fff91055f06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00007fff91055f06 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x000000010008142d libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x00007fff96dc76e7 libsystem_c.dylib`abort + 129
frame #3: 0x00007fff8973bf81 libc++abi.dylib`abort_message + 257
frame #4: 0x00007fff89761a47 libc++abi.dylib`default_terminate_handler() + 267
frame #5: 0x00007fff94f636ae libobjc.A.dylib`_objc_terminate() + 103
frame #6: 0x00007fff8975f19e libc++abi.dylib`std::__terminate(void (*)()) + 8
frame #7: 0x00007fff8975ec12 libc++abi.dylib`__cxa_throw + 121
frame #8: 0x00007fff94f6108c libobjc.A.dylib`objc_exception_throw + 318
frame #9: 0x00007fff8d067372 CoreFoundation`-[__NSPlaceholderArray initWithObjects:count:] + 290
frame #10: 0x00007fff8d0eaa1f CoreFoundation`+[NSArray arrayWithObject:] + 47
* frame #11: 0x0000000100001b54 test`main(argc=1, argv=0x00007fff5fbff808) + 68 at main.m:15
frame #12: 0x00007fff8bea05ad libdyld.dylib`start + 1
frame #13: 0x00007fff8bea05ad libdyld.dylib`start + 1
SIGABRTとEXC_BAD_INSTRUCTIONのクラッシュをデバッグする
SIGABRT
またはEXC_BAD_INSTRUCTIONは通常、何らかのチェックが失敗したためにアプリが意図的にクラッシュしたことを意味します。これらは、デバッガのコンソールにメッセージを記録して、詳細情報を表示する必要があります。詳細についてはそこにチェックしてください。
多くのSIGABRT
されていないObjective-C例外によって引き起こされます。例外がスローされる可能性がある、と彼らは常にコンソールに役立つ多くの情報をログに記録する多くの理由があります。
-
NSInvalidArgumentException
は、アプリケーションが無効な引数をメソッドに渡したことを意味します -
NSRangeException
は、アプリケーションがNSArray
やNSString
などのオブジェクトの範囲外インデックスにアクセスしようとしたことを意味します -
NSInternalInconsistencyException
は、予期しない状態にあることが検出されたオブジェクトを意味します。 -
NSUnknownKeyException
は、通常、XIBに不正な接続があることを意味します。 この質問への答えのいくつかを試してみてください。
EXC_BAD_ACCESSのデバッグ
EXC_BAD_ACCESS
は、 NULL
ポインタの逆参照や読取り専用メモリへの書込みなど、無効な方法でメモリにアクセスしようとしたプロセスを意味します。これは通常、エラーメッセージを持たないため、デバッグするのが最も難しい種類のクラッシュです。一部のクラッシュは、再現するのが非常に難しく、問題に完全に関係しないコードで発生する可能性があります。このエラーはSwiftでは非常にまれですが、発生した場合、コンパイラの最適化を減らすことで、デバッグが簡単にクラッシュすることがよくあります。
ほとんどのEXC_BAD_ACCESS
エラーは、 NULL
ポインタを逆参照しようとしたために発生します。この場合、赤い矢印に表示されているアドレスは通常、通常のメモリアドレス( 0x0
よりも低い16進数になります。デバッガでブレークポイントを設定するか、時折printf
/ NSLog
ステートメントを追加して、そのポインタがNULL
理由を調べNULL
。
あまり信頼性が低いか、まったく意味がないEXC_BAD_ACCESS
は、メモリ管理の問題の結果である可能性があります。これを引き起こす一般的な問題は次のとおりです。
- 割り当てが解除されたメモリを使用する
- C配列や他の種類のバッファの終わりを過ぎて書き込みしようとしています
- 初期化されていないポインタを使用する
Scheme EditorのDiagnosticsセクションには、メモリの問題をデバッグするのに役立つツールがいくつか用意されています。
Address Sanitizerは、メモリの問題が発生するたびにアプリケーションを停止させるチェックを数多く追加し、起こったことを正確に詳述する有用なエラーメッセージを提供します。ゾンビオブジェクトは、Objective-Cオブジェクトの割り当て解除の問題を検出しますが、Automatic Reference Countingをオンにすると、このような問題は発生しません。