6

最近、ヒープの破損を伴う最初の戦い (解決済み)に遭遇しました。自宅の Linux マシンでは、valgrind と electric-fence (gdb を使用) を使用して、犯人コードがエラーなしで終了します。しかし、私たちの研究室の Windows マシンでは、参照した投稿で説明されているように、VS から一貫してヒープの破損に関連するエラー メッセージが表示されます。

valgrind と電気柵がそのような問題を検出しないのは驚くべき (または少なくとも珍しいこと) でしょうか? 他の誰かが、こちらの回答でvalgrindを逃した可能性のある同様のバグについて言及しました。これらのツールでこの問題が検出されない理由は何ですか? エラーが実際にヒープの破損であることを疑う理由はありますか?

更新:元の問題を説明した投稿で述べたように、問題は std::vector 内の要素へのポインターが原因であることがわかりました。これは悪くなりました。ベクトルを std::list (新しい要素を追加してもポインターが無効にならない) に置き換えると、問題が修正されました。valgrind が問題を検出しなかった理由についての私の質問に戻りますが、今後同様の状況、つまり valgrind によって検出されないメモリの問題を回避する方法についての推奨事項があるかどうかを尋ねます。お気に入りのツール。STL がどのように機能するかをよりよく理解することは、明らかに良い考えです。おそらく、プログラミングなどで assert を使用してより積極的になる必要があります。

4

3 に答える 3

6

したがって、Valgrindがヒープの破損を検出できなかった明らかな理由は、GCC STLの実装では破損がまったく発生しなかったためです（つまり、検出するエラーはありませんでした）。

残念ながら、ValgrindはSTLよりもはるかに低いレベルで動作するため、多くのバグが検出されないままになっています。例えば：

std::vector<int> v;
v.push_back(1);
v.push_back(2);
v.resize(0);
v[1] = 42;  // Oops. Out of bounds access, but Valgrind is silent

幸い、GCC STLには、このような多くの問題をキャッチするように設計された特別なデバッグモードがあります。を使用して元のコードを作成してみてください-D_GLIBCXX_DEBUG。元の問題をキャッチする可能性が高く、まだ知らない問題をさらにキャッチする可能性があります。

于 2011-04-27T04:16:12.693 に答える
0

ヒープの破損が何であるかを理解していません。特に、メモリリークはヒープの破損ではありません。

Parallel Studioによって報告されたメモリリークも偽物のようであり、プログラムよりもParallelStudioのバグである可能性が高くなります。

于 2011-04-25T03:38:14.490 に答える
0

同じツールを使用して、あるマシンでは良い結果が得られ、別のマシンでは悪い結果が得られる場合は、開発用マシンでいくつかのメモリ テストを実行することをお勧めします。memtest86 の起動可能なイメージは簡単に取得でき、特定のメモリ エラーによって問題が明確に説明される場合があります。

一方、各マシンで異なるオペレーティング システムを使用している場合は、使用しているクロスプラットフォーム ライブラリの Windows バージョンにバグが存在する可能性もあります (おそらくそれ以上の可能性があります)。

于 2011-04-25T03:05:47.170 に答える