25

iPhone アプリで EXC_BAD_ACCESS をデバッグしようとしています。メソッド呼び出しでクラッシュし、メソッドの行で isEXC_BAD_ACCESS (code=1, address = xxx)です。

以前はgdb info malloc-history <xxx>デバッグを開始するだけだったのですが、 で並列コマンドを見つけるのに苦労していLLDBます。

Instrumentsを使用するように言ったこのスレッドを見ましたが、それでもクラッシュしますが、アプリがInstrumentsのどこからクラッシュしているのかを正確に知る方法がわかりません。

クラッシュしているこのメモリの断片がどこを指していたのかを突き止める必要があります。LLDBまたはインスツルメンツを使用してこれを行う最良の方法は何ですか?

4

4 に答える 4

44

インストルメントを使用してデバッグすると、malloc スタックを確認できます。

私はあなたと同じ問題に遭遇し、同様にlldbを使用するときにmalloc履歴を取得する方法を知りたいと思っていました. 残念ながらmalloc-history、gdb にあるような気の利いたコマンドは見つかりませんでした。正直なところ、デバッガーを切り替えたばかりですが、そうする必要はないと感じていたので、面倒でした。

インストゥルメントを使用して malloc 履歴を見つけるには、次のようにします。

  1. プロジェクトのプロファイリング
  2. 楽器のリストからゾンビを選択します ここに画像の説明を入力
  3. アプリが問題を引き起こすようにする
  4. この時点で、既に割り当てが解除されたアドレスが表示され、それを調べることができます。 ここに画像の説明を入力 この時点で malloc の履歴を表示するのは簡単なことです。私がやっている仕事に固有のクラス/プロジェクト名を持つ部分を黒塗りしましたが、これらの情報を取得する方法の本質と有用性は存在すると思います.

最後の言葉

私が遭遇した問題は、次のようなメッセージを生成しました:

*** -[someClass preserve]: 割り当て解除されたインスタンス 0x48081fb0 に送信されたメッセージ someProject(84051,0xacd902c0) malloc: 標準レコーダーを使用して malloc スタックをディスクに記録します

retainそれが壊れていたコードにはそれがなかったので（それがあった行のゲッターまたはセッターにはありませんでした）、私はこれがどこから来ているのか本当に困惑しました。removeObserver:forKeyPath:特定のオブジェクトがdealloc編集されたときに、私が呼び出していなかったことが判明しました。実行の後半で、KVO が行のセッターに対して行われ、KVO が既に解放されたオブジェクトに通知しようとしたため、プログラムが爆発しました。

于 2012-03-26T20:56:54.443 に答える
38

この問題は、有益なバックトレースを使用して非常に簡単に解決できます。残念ながら、iOS と Xcode の最新バージョンでは、適切なスタック トラックを入手するのが難しい場合があります。幸いなことに、Xcode で「例外ブレークポイント」を設定して、EXC_BAD_ACCESS 例外の前にこのコードを調べることができます。

  1. Xcode 4 でブレークポイント ナビゲーションを開きます (これは、右側にポイントがある長方形のように見えます)。
  2. 左下の「+」ボタンを押して、「例外ブレークポイント」を追加します。「すべて」の例外の「オンスロー」を中断してください。

この例外が発生する直前に完全なバックトレースを取得する必要があります。これにより、この例外がスローされている場所に少なくとも焦点を合わせることができます。

于 2012-03-27T14:11:40.520 に答える
15

lldbで次のようなコマンドを使用できます。

image lookup --address 0xec509b

その他のコマンドは次の場所にあります：LLDB TO GDB COMMAND MAP

于 2012-09-10T05:56:59.070 に答える
10

遅すぎるかもしれませんが、さらなる支援が必要な場合は、LLDB で:

(lldb) p *(MyClassToPrint*)memory_address

例えば

(lldb) p *(HomeViewController*)0x0a2bf700
于 2014-01-08T18:52:51.503 に答える