デバッガーを使用していない場合にのみsegfault

Question

マルチスレッドCプログラムがあり、プログラムの特定のポイントでセグメンテーション障害を一貫して生成します。 GDBで実行すると、障害は表示されません。デバッガーを使用していない場合にのみ障害が発生する理由を考えることができますか？問題を見つけるためにそれを使用できないことはかなり迷惑です！

Answer 1

クラシック heisenbug. 。ウィキペディアから：

また、時間はハイゼンバグの要因になる可能性があります。デバッガーの制御下にあるプログラムを実行すると、通常の実行と比較して、プログラムの実行タイミングを変更できます。レース条件などの時間に敏感なバグは、デバッガーのシングルステップソースラインによってプログラムが遅くなったときに再現しない場合があります。これは、2つのマシン間でネットワークパケット処理をデバッグする場合、1つだけがデバッガー制御下にある場合など、動作がデバッガーの制御下にないエンティティとの相互作用を伴う場合に特に当てはまります。

デバッガーはタイミングを変更し、レース条件を隠している可能性があります。

Linuxでは、GDBはアドレススペースのランダム化も無効にし、クラッシュはアドレススペースレイアウトに固有の場合があります。試す (gdb) set disable-randomization off.

ついに、 ulimit -c unlimited そして、死後のデバッグ（すでにロビーが提案している）が機能する可能性があります。

Answer 2

おそらく使用するとき gdb メモリは、オーバー/アンダーフローがクラッシュを引き起こすメモリを踏みにじらない場所にマッピングされます。または、もはやトリップされていない人種状態である可能性があります。それは直感的ではないように聞こえますが、あなたはそうあるべきです ハッピー あなたのプログラムはあなたにクラッシュするのに十分親切でした。

いくつかの提案

1. 無料などの静的コードアナライザーを試してくださいcppcheck
2. malloc（）デバッガーのようなものを試してくださいlibefence
3. 実行してみてください Valgrind

Answer 3

デバッグすることで、走っている環境を変えています。ある種の人種状態に対処しているように聞こえます。デバッグすることで、物事がわずかに異なってスケジュールされているため、問題に遭遇しません。それ、または物事はわずかに異なる方法で保管されているので、それは発生しません。コードにデバッグ出力を配置して、問題の把握を支援することができますか？それは影響が少なく、あなたの問題を見つけることができるかもしれません。

Answer 4

私は以前に完全にこの問題を抱えていました！それは人種の状態であり、私がデバッガーでコードを介して踏み込んでいたとき、私が入っていたスレッドは、人種の状態を引き起こさないほど遅くなりました。かなりひどい。