1 
2013-01-08 16:02:55.341 TodayApp[95470:14003] -[__NSCFBoolean objectForKey:]: unrecognized selector sent to instance 0x9b4964
2013-01-08 16:02:55.342 TodayApp[95470:14003] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFBoolean objectForKey:]: unrecognized selector sent to instance 0x9b4964'
*** First throw call stack:
(0x883012 0x20a2e7e 0x90e4bd 0x872bbc 0x87294e 0x7afc 0x234353f 0x2355014 0x23457d5 0x829af5 0x828f44 0x828e1b 0x2dcf7e3 0x2dcf668 0xfea65c 0x2679 0x2585)
libc++abi.dylib: terminate called throwing an exception

私のアプリには、ほぼ 30 のクラスがあります。特定の VC に入ると上記のエラーが発生しますが、10 回に 1 回しか発生しないため、再現する方法がありません。これを効率的にデバッグするにはどうすればよいですか? 通常、私は NSLog を使用して段階的に「デバッグ」しますが、より効率的な方法で私を啓発できると確信しています。

更新:これは問題のある行です:NSString *card = [NSString stringWithFormat:@"%@-%@",[[UserAccount sharedInstance] cardNumber],[tokenData objectForKey:@"CardPhoneToken"]]; 私はまだそれの何が問題なのかを理解しようとしています.

4

3 に答える 3

2

最初に例外ブレークポイントを設定します。その場合、例外がスローされた時点で有用な出力が表示されない可能性があります。ただし、コードがスローされた場所に、コードの一部が表示されるはずです。それは大いに役立ちます。その後、デバッガーで [実行を続行] をおそらく 2 ～ 3 回押すと、最終的にデバッグ コンソールにエラー メッセージが表示されます。それまでにメイン関数が表示されるかもしれませんが、それまでに、例外の発生源がどこにあったかをすでに確認しています。

さて、まさにそのコード行で扱っているすべてのオブジェクトを見てみましょう。これらのオブジェクトの 1 つ (またはこれらのオブジェクトの任意のプロパティ) は NSDictionary であると想定されています。これは、エラー メッセージが示すように、"objectForKey:" メッセージが送信されましたが、適切なセレクターが見つからなかったためです。これは、問題のオブジェクトが Boolean/NSBoolean 型であるためです。

ほとんどの場合、数値オブジェクトまたはポインターを NSDictionary であると想定されるものに割り当てています。たまたまブール型のものを指している初期化されていないポインターにアクセスしている可能性があります。その場合、エラーの再現が難しい場合があります。

ただし、そうすることで正しい軌道に乗ることができます。

于 2013-01-08T14:42:59.527 に答える
0

スロー時とキャッチ時のすべての例外に対して例外ブレークポイントを設定します。

これは、BreakPointNavigatorの右下の「+」記号で実行できます。例外ブレークポイントを追加...そしてBreak：On Throwを選択し、OnCatch用に別のブレークポイントを作成します

これにより、例外が生成されている場所を特定するのに役立つブレークポイントが作成されます。

より面倒な方法は、dSYMファイルを作成してatosコマンドを実行することです。

これは、プロジェクトをアーカイブすることによって行われます。次に、オーガナイザーでアーカイブを右クリックし、ファインダーに表示します。次に、右クリックしてパッケージの内容を表示します。TestApp.app.dSYMを便利な場所にコピーし、ターミナルでそこに移動します。

次に、次のように入力します。

cd Contents/Resources/DWARF/

次に、atosコマンドを実行できます。

atos -arch armv7 -o TestApp 0x7556fb0

ここで、TestAppはアプリ名であり、0x7556fb0は調査するアドレスです。あなたの場合、それは0x883012である可能性があります。

場合によっては、クラッシュが発生した場所のクラスと行番号がわかることがあります。好き：

[Class methodName:]; -211

時々機能するように見える別の方法は、 HockeyApp用にアプリを設定することです。このようにして、クラッシュレポートをHockeyAppに送信でき、そこでより詳細な情報を取得できる場合があります。dSYMファイルもアップロードすると便利です。

于 2013-01-08T14:23:05.313 に答える
0

この例外は簡単にデバッグできます。すべての objectForKey: 呼び出しを検索し、これをブール値に送信できる場所を確認してください。

または、そのような呼び出しを含むコード行が多すぎる場合は、コール スタックをシンボル化できます: iPhone アプリ クラッシュ レポートのシンボル化

于 2013-01-08T14:25:43.920 に答える