gdbで実行したときに致命的なエラーが消えた

Question

テストケースで致命的なエラーを生成するプログラムがあり、ログとスタックトレースを読み込み、読み取り操作があることがわかりましたヌルポインタのとき。

しかし、私はそれにgdbを接続し、疑わしいコードの周りにブレークポイントを設定しようとすると、nullポインタだけが観測できません！このプログラムはエラーなくスムーズに動作します。

これはシングルプロセスのシングルスレッドプログラムであり、以前はこのようなことは経験していませんでした。誰か私にいくつかのコメントを与えることができますか？ありがとう。

追加：致命的なトリガコードの前にpause（）syscallも呼び出そうとしましたが、致命的なポイントの前にプログラムをスリープ状態にしてからgdbをon-the-flyでアタッチすることが予想されます。

Answer 1

それはコードを見ずに唯一の当て推量ですが、デバッガは時々これを行う：あなたが

動作のタイミングが変更されたため

• 彼らは

私はドン、特定のものを初期化する」をGDBの見積もりはありますが、私はvalgrindを持っています（2つ与えられてとなりまして異種..）

My program crashes normally, but doesn't under Valgrind, or vice versa. What's happening?

プログラムがValgrindの下で実行すると、 その環境は、それがネイティブに実行したときに 若干異なっています。たとえば、メモリのレイアウトが で、スレッドのスケジュール方法が の場合は、 が異なります。

GDBの場合も同様です。

は、時間の大半は、このいずれかの 違いはありませんが、それはあなたのプログラムにバグがある特に 場合は、することができます。

あなたのプログラムには本当の問題がありそうです。

Answer 2

ポインタに対する無効な読み取りの場合、予測不可能な動作が可能です。あなたはすでに何が原因であるかを知っているので、できるだけ早くそれを取り除くべきです。一般的に、誤ったポインタ操作を扱うときは予期せぬことが予想されます。

Answer 3

アプリケーションのタイミングが変更される可能性があるため、マルチスレッドアプリケーションの場合は、まずreadyフラグを設定してから、バッファにデータをコピーすることができますバッファがいっぱいになるか、何らかのポインタが設定される前に、他のスレッドがアタッチしたデバッガがバッファにアクセスする可能性があります。

アンチ・デバッグ機能を持つアプリケーションもあります。おそらく、デバッガの内部で実行されているときには、コードの一部に触れることはありません。

これを分析する1つの方法は、コアダンプを使用することです。あなたは、アプリケーションを起動し、コアをダンプしたとき、あなたはここに役立ち、ライトアップを見つけることができますgdb ./application ./coreとGDBにロードすることができ、その後ulimit -c unlimitedで作成できる： `valgrind` /` memcheck`とhttp://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php