例外ブレークポイント - LLDB結果対GDB

Question

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

グローバルテストのXcode 4.2

• 値。1
• 新しいシングルウインドウプロジェクト
• アークが
• ストーリーボードが

ケース1有効有効（変更なし/ wのデフォルトのテンプレート） - GDBデバッガ

例外ブレークポイント値：

を

• 例外 - すべて
投げ
• 引数 - - 上
• 休憩なし
• 結果 - ノークラッシュ

ケース2 - LLDBデバッガ

例外ブレークポイント値：

• 例外 - すべて
• ブレイクオン - スロー
• 引数なし -
• 結果 - Sigbartによるクラッシュ&マシンコード;識別可能なスタックトレース

ケース3 - LLDBデバッガ

例外ブレークポイントの値はありません：

• 例外 - Objective-Cの
上
• ブレイク -
• 引数を投げる - なし
• 結果 - クラッシュなし

ケース4 - LLDBデバッガ

例外ブレークポイント値：

• 例外 - なし
• 結果 - - Sigbartとクラッシュ
• 引数を投げる - 上のC++
• ブレイクマシンコード。識別可能なスタックトレース

質問：私は単に例外のオプションとして、「Objective-Cの」を選択すると、行くための安全な方法であることを想定する必要があり、または私は潜在的に明白な問題を無視するのですか？ありませんかXcode 4.2.1以降、LLDBを使用することをお勧めします。しかし、私は上記の結果に不思議です。

すべてのコミュニティの対応に感謝します！

Answer 1

@Mike Kという慎重な提案のおかげで、私は、目立った問題を無視する可能性があるという懸念に対処することができました。

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

私は後発のためにシミュレータの問題の根本的な原因に関心がありますが、意図したとおりにLLDBを使用して進めることができてとても嬉しいです。