デバッグセッションでSigtrapが発生する原因
私のC++プログラムでは、「送信しますか？」というライブラリを使用しています。デバッグ中の特定の操作のSigtrap（gdbをデバッガーとして使用）。その後、プログラムを続行するか停止するかを選択できます。続行することを選択した場合、プログラムは期待どおりに動作しますが、Sigtrapがキャッチされた後にカスタムブレークポイントを設定すると、デバッガー/プログラムがクラッシュします。
だからここに私の質問があります：
- このようなSigtrapの原因は何ですか？それは削除できるコードの残りの行ですか、それともデバッガが「好きではないものを見つけた」ときに引き起こされたものですか？
- 一般的に言って、シグトラップは悪いことですが、もしそうなら、なぜデバッグバージョンではなくリリースをコンパイルするときにプログラムが問題なく実行されるのですか？
- Sigtrapは何を示していますか？
これは昨日投稿した質問へのより一般的なアプローチですブーストファイルシステム：recursive_directory_iteratorコンストラクターはSIGTRAPSとデバッグの問題を引き起こします 。
私の質問は具体的なものではなかったと思います。私の問題を解決したくはありませんが、背景を理解するのを助けてください。
どうもありがとう。
命令ブレークポイントまたはデータウォッチポイントをサポートするプロセッサでは、デバッガーは特定のアドレスへの命令アクセス、または特定のアドレスへのデータの読み取り/書き込みを監視するようCPUに要求し、フルスピードで実行します。
プロセッサがイベントを検出すると、カーネルにトラップされ、カーネルはデバッグ中のプロセスにSIGTRAPを送信します。通常、SIGTRAPはプロセスを強制終了しますが、デバッグ中のため、デバッガーはシグナルの通知と処理を行います。ほとんどの場合、実行を継続する前にプロセスの状態を検査できます。
ブレークポイントまたはウォッチポイントをサポートしていないプロセッサでは、デバッグ環境全体がおそらくコード解釈とメモリエミュレーションによって行われますが、これは非常に遅いです。 （ページテーブルフラグを設定して読み取りまたは書き込みのいずれかをトラップする必要があり、カーネルにページテーブルを修正させ、デバッガーに信号を送り、ページフラグを再度制限することにより、巧妙なトリックを行うことができると思います。 -ウォッチポイントとブレークポイントの任意の数。ウォッチポイントまたはブレークポイントが頻繁にアクセスされない場合は、実行速度がわずかに低下します。
コメントフィールドに入れた質問は、Windowsが実際にSIGTRAPを送信しておらず、独自の方法でブレークポイントを通知しているために適切です。プログラムをデバッグするときは、システムライブラリのデバッグバージョンが使用され、メモリアクセスが意味をなすように見えることを確認します。実行時にペーパーオーバーされるプログラムのバグがあるかもしれませんが、実際には他の場所でさらに問題を引き起こしている可能性があります。
Windowsでの開発は行っていませんが、Windowsイベントログを調べることで詳細を確認できますか？
EclipseでminGW/gccコンパイラーを使用していると、コード内のベクトルに対して非常に悪い反応があり、不明瞭なSIGTRAPシグナルが発生し、時には異常なデバッガー動作を示すこともありました（つまり、コード内のどこかにジャンプして、逆順！）。
プロジェクトからVisualStudioにファイルをコピーし、問題を解決してから、変更をEclipseと出来上がりにコピーしました。理由は、reserve（）関数とresize（）関数のベクトル初期化の違い、またはベクトル配列の境界外の要素にアクセスしようとしたようなものでした。
これが他の誰かを助けることを願っています。