2

この質問に特化したトピックを検索しましたが、私の経験に近いものは見つかりませんでした。私が答えを見落としていたら、私を許してください。私は GDB と例外ポイント、ブレーク ポイントなどに精通していますが、GDB と LDB でのデバッグの次のテストでは、もっともらしい応答がありませんでした。

グローバル テスト値

  • Xcode 4.2.1
  • 新しい単一ウィンドウ プロジェクト (変更なしの既定のテンプレート)
  • アーク有効
  • ストーリーボード有効

ケース 1 - GDB デバッガー

例外ブレークポイントの値:

  • 例外 - すべて
  • ブレイクオン - スロー
  • 引数 - なし
  • 結果 - クラッシュなし

ケース 2 - LLDB デバッガー

例外ブレークポイントの値:

  • 例外 - すべて
  • ブレイクオン - スロー
  • 引数 - なし
  • 結果 - Sigbart とマシンコードでクラッシュ。識別可能なスタック トレースがない

ケース 3 - LLDB デバッガー

例外ブレークポイントの値:

  • 例外 - 目的 C
  • ブレイクオン - スロー
  • 引数 - なし
  • 結果 - クラッシュなし

ケース 4 - LLDB デバッガー

例外ブレークポイントの値:

  • 例外 - C++
  • ブレイクオン - スロー
  • 引数 - なし
  • 結果 - Sigbart とマシンコードでクラッシュ。識別可能なスタック トレースがない

質問:例外オプションとして「Objective-C」を選択することが安全な方法であると単純に想定する必要がありますか?それとも、重大な問題を無視している可能性がありますか? Xcode 4.2.1 の時点で、LLDB を使用することをお勧めします。しかし、上記の結果が気になります。

すべてのコミュニティの回答に事前に感謝します!

4

1 に答える 1

0

@Mike Kの思慮深い提案のおかげで、明白な問題を無視する可能性があるという私の懸念に対処することができました。

上記のシナリオを実際のデバイスiPhone/iPadで再現すると、 LLDBを使用したケース2と4でクラッシュが発生しなくなり、アプリケーションは意図したとおりに実行されます。問題はシミュレーターに限定されているようです。

後世のためにシミュレーターの問題の根本原因に興味がありますが、意図したとおりにLLDBを使用して続行できることを非常に嬉しく思います。

于 2012-01-25T17:45:21.347 に答える