4

LLDB で使用可能な情報を取得するために必要な魔法の呪文を理解する助けが必要です。

デバッグしようとしている奇妙な動作があり、問題を確実に再現できますが、根本的な原因はまだわかりません。例外がスローされていることに気付いたので、Xcode に例外ブレークポイントを追加しました。

例外：

CoreData: エラー: 重大なアプリケーション エラーです。-controllerDidChangeContent: の呼び出し中に、NSFetchedResultsController のデリゲートから例外がキャッチされました。*** -[__NSArrayM objectAtIndex:]: userInfo (null) を持つ空の配列の境界を超えたインデックス 2

したがって、ブレークポイントを配置すると、次のスタック トレースが得られます。

スタックトレース

これはとても役に立ちます！再利用可能なヘッダー ビューの UICollectionViewFlowLayout でいくつかのファンキーさが起こっているようです...今、私はただする必要があります...ああ。くだらない。待つ。何？

範囲外のインデックスで呼び出されているスタック トレースのフレーム 1 の配列を調べるにはどうすればよいですか? po <some memory address>コンソールで確認できますか? frame variableフレーム11-1が選択されている場合、LLDBコンソールで使用できません（ここから）。

このスタック トレースを読み取る方法は次のとおりです。

  1. (フレーム 14)フェッチされた結果コントローラーは、管理対象オブジェクトのコンテキストの変更を取得し、そのデリゲートを呼び出します
  2. (フレーム 13)のインスタンスである FRC デリゲートは、のサブクラスであるView ControllerにFHMemberDirectoryメッセージを送信します。-memberDirectoryDidChangeContent:completion:FHMemberDirectoryViewControllerUICollectionViewController
  3. (フレーム 12)-performBatchUpdates:completion: UICollectionView インスタンスのビュー コントローラー呼び出し
  4. (フレーム 10 - 1) Apple のプライベートな要素がたまたまコレクション ビューを画面にレイアウトしようとしました。おもう！

... 明らかに明らかなことを見逃していたら教えてください! この質問はデバッグに関するものであり、別の目またはより多くの専門知識が私を啓発してくれることを願っています。

素人目には、これは Apple のコードに埋もれたバグのように見えますが、それでも回避する方法を見つける必要があります。私の問題のこの要点は、直接制御できないコードで LLDB コンソールから有用な情報を取得する方法を理解することです。

4

1 に答える 1

1

私の実験と研究から、答えは次のとおりです。

LLDB だけでは、検査に役立つシンボルやメモリ アドレスを取得できません。

ただし、Objective-C ランタイムを使用して、メソッドの実装をスウィズルし、深いスタック トレースにジャンプすることで、引数と戻り値へのハンドルを提供できます。

メソッドが入れ替わったスタック トレース

これで、フレーム 3 と 5 で渡された引数にアクセスできるようになりました!

( の引数は Apple のプライベート クラスであることが判明しました。ここ...usingData:でクラスについてさらに掘り下げることができましたが、特に役立つものは何もありませんでした。1 日の終わりにレーダーを提出し、回避策の助けを求めました。 DTS から)。

于 2013-05-28T15:07:25.463 に答える