問題タブ [lldb]

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

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

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

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

iOSアプリをデバッグしようとしていますが、シミュレーターのlldbに問題があります。クラスメソッドの呼び出しは機能していないようです。インスタンスメソッドは正常に機能します。

4.3と5.1のシミュレーターを試しましたが、どちらも同じ問題を示しています。

デバイスでデバッグする場合、すべてが正常に機能します。

私はここで少し凝ったことをしようとしていますが、ドキュメントはそれが可能であるはずだと示唆しています。LLDBはまだ新しすぎるかもしれませんが、デバッガーのクラッシュやデッドロックが頻繁に発生しており、それが発生しない場合でも、期待どおりに機能していないようです。

コードの特定のチャンク内にメッセージコールグラフを抽出するために、すべてのセレクター呼び出しの周りにデバッグラッパーをまとめようとしています。（本当に知りたいのであれば、その理由を説明できますが、デバッガーの問題にはあまり関係ありません。）

追跡を開始したい行のXcodeブレークポイントから始めます（ボーナスポイントの場合、これはセカンダリスレッドで発生しますが、質問する前に、他のスレッドではこのオブジェクトへのアクセスを行っていません。そのプロパティサブグラフのすべて）：

ブレークポイントがトリガーされ、以下を抽出するために「bt」を実行します。

次に、やや邪悪なことをします。実際のオブジェクトセレクターを呼び出す命令のすぐ近くにあるobjc_msgSendにブレークポイントを設定します。objc_msgSendは次のようになります：

（実際には2つのbx呼び出しがありますが、物事を単純に保ちましょう。）私は実行します：

（この1つのスレッドを追跡するのに十分な問題があり、無関係なものが干渉する必要がないため、TIDが含まれています。）

ここでスクリプトが登場します。上記の設定は、私が望むとおりに機能します。ブレークポイントがトリガーされるまで実行を再開すると、次のように実行できます。

その結果、デバッガーは次のようになります。

• objc_msgSendフレームに移動します
• 1つの命令でステップし、それをポイントしていたオブジェクトセレクターフレームに進めます
• 関連する詳細を表示します（オブジェクトタイプ、呼び出されるセレクター）
• 実行を再開します

その時点で、これらの4つのコマンドを何度も貼り付け、自分が嫌いになるまで出力をコピーし続けることができます。

一方、私が実行した場合：

まったく同じコマンドを貼り付けると、すべてが壊れます。オブジェクトセレクターフレームには進みません。フレームの詳細は表示されないか、少なくとも正しいものは表示されません。さまざまな調整（以下を参照）に応じて、「objc_msgSend」が現在の関数として表示される場合と表示されない場合があります。実行を再開しません。

この場合、その例を機能させることができれば、私は大体幸せになるでしょう。しかし、さらに多くのボーナスポイントについては、Pythonでこれを試しました。これにより、はるかに高度なロギングが可能になるため、次のようになります。

再びダメ。繰り返しますが、細部に応じて、これは何か（通常はobjc_msgSend）を印刷する場合としない場合がありますが、正しいものを印刷することはありません。命令を前に進めることはありません。その後、実行を再開することはありません。

繰り返しになりますが、Pythonバージョンは、手動で実行すると正常に機能します。ブレークポイントが発生するまで待ってから「script」を実行し、まったく同じ行を入力すると、期待どおりに機能します。一部のパーツは単独でも機能します。たとえば、プロセスを取得してprocess.Continue（）を呼び出し、それらを自動的にトリガーする部分を除くすべてを削除すると、「機能」します（つまり、lldbプロンプトが一時停止および再開すると、すばやく点滅します。実行。通常、これは応答しなくなり、すぐにクラッシュするため、後悔しています。）

だから：何かアイデアはありますか？テクノロジーはまだ準備ができていませんか、それともすべてを修正するパズルの巧妙な部分が欠けていますか？それとも、私は完全に諦めて、私が理解できないオブジェクトの内部のいくつかの部分があるという事実だけで生きるべきですか？...

一部の iOS コードではstruct、オブジェクトに C ivar があります。この構造体のメンバーの 1 つはタイプdoubleです。メソッド内でこのメンバーに割り当てると、デバッガーは、(変数のリスト ビューと同様に) メンバー自体を出力するときにstruct、このメンバーの値に対して誤った値を報告しますが、メンバーを直接出力すると ( )、私は正しい値を取得します。さらに、このメンバーの値をローカルの自動変数に割り当てると、リスト ビューと印刷時に正しい値が表示されます。structstructstructp structWithDouble.doubleMemberdouble

これは LLDB の問題だと思いますが、不安でイライラします。これは既知の問題ですか? もしそうなら、回避策はありますか？

例

内部someMethod:のデバッガ変数リストには、次の値が表示されます。

LLDB に侵入すると、次の出力が得られますsomeMethod:。

アップデート

GDB を使用している場合、このような動作は発生しないことがわかりました。どうやら LLDB はまだ準備ができていないようです...ただし、LLDB の回避策にはまだ興味があります。

Xcode では、GDB を使用してデバッグ中にローカル変数を変更できます ( XCode でデバッグ中に NSString 値を変更する方法を参照してください)。LLDB は同様の機能を提供しますか? もしそうなら、どうやってそれを使うことができますか?

私のアプリケーションは最近、エラーや例外なしでランダムにクラッシュするようです。コンソールは(lldb)水色で表示されます。キャッチされていない例外処理がありますが、まだ何もありません。それはランダムな時間に発生します。私は同じタスクを何度も行うことができますが、発生する場合と発生しない場合があります。また、アプリケーション内のランダムな場所で発生することもあります。

これまでに読んだことはlldb、アプリではなくデバッガーがクラッシュしている可能性があるということですが、以前は気づいていませんでした。

クラッシュの原因を突き止める方法はありますか?

アプリケーションに MBProgressHUD を追加したときに始まったようです。

intValueデバッガーでテキスト フィールドのテキストを出力できないのはなぜですか?

私は現在、Xcode4.3.2でiOSアプリを書いています。私のコードのほとんどの部分で、LLDBを使用したデバッグは問題なく機能します。ただし、ある時点で、コードをステップ実行しているときに奇妙なメッセージが表示されます。iVarにカーソルを合わせると、

エラー[IRForTarget]：Objective-Cの間接ivarシンボルOBJC_IVAR _ $_MyFancyClass.iVarが見つかりませんでした

値を表示する代わりに。しかし、ではVariables View、私はそれをうまく見ることができます。それを選択するまでPrint Description of ...は、Xcodeがクラッシュするためです... GDBを使用すると、ホバリングは機能しますが、変数のタイプと値が間違っています。

コードに問題があり、デバッガーが失敗する原因になっていることを確認しました。ただし、コードは正常に実行されます。サンプルコードを提供したいのですが、クラスがかなり長く、ねじ込みの正確な場所を特定できません。それで、誰かが同様の行動に遭遇したことがありますか？

更新：実際、これは特定のファイルだけでなく、コードのどこでも発生しているようです。それが役立つ場合、LLDBは上記のメッセージを表示しますが、GDBは、iVar自体ではなく、iVarを所有しているクラスのオブジェクトを常に表示します。メモリ管理に問題があるように見えます。たとえば、私が次のようなことを言うと

セレクターは私が持っているときでも呼び出されます

iOS シミュレーターは、main.m に起因する SIGABRT シグナルを発行しています。

main.m を変更していないので混乱しています。デバッガーをバックトレースすると、常にメイン関数が返されますが、これは役に立ちません。

iOS で SIGABRT シグナルをデバッグするにはどうすればよいですか? XCode が、私が書いたどの行がシグナルを発生させたかを教えてくれたらいいのにと思います。

プログラムを終了した後にコンソールが発行するものは次のとおりです。

これが何を意味するのか、それとも SIGABRT の発行に直接関係しているのかはよくわかりません。

Mac OS X のターミナル コマンドラインから GDB または LLDB を使用して、iOS シミュレーターで実行されているアプリをデバッグすることはできますか? (たとえば、Xcode の GUI またはコンソール内からではなく、外部のコマンドラインまたはプロセスを使用します)。もしそうなら、どのように？