我最近遇到了我的第一个battle （已解决）堆损坏。在我家的linux机器上，使用valgrind和电栅栏（使用gdb），罪魁祸首代码无错误地退出。然而，在我们实验室的Windows机器上，我始终从我引用的帖子中描述了VS中与堆损坏相关的错误消息。
valgrind和电围栏不会发现这样的问题，这是否令人惊讶（或至少不常见）？其他人提到了一个可能类似的错误，在回答here中找不到valgrind。这些工具无法检测到此问题的原因可能是什么？有没有理由怀疑错误实际上是堆腐败？
更新：正如在描述原始问题的帖子中所提到的，我发现问题是由于指向std :: vector中的元素指针，这变得很糟糕。用std :: list替换向量（添加新元素时指针不会变为无效）修复了问题。所以回到我关于为什么valgrind没有发现问题的问题，我问是否有关于如何避免将来出现类似情况的建议，即valgrind未检测到的内存问题，这是我的一个问题最喜欢的工具显然，更好地了解STL如何工作将是一个好主意。也许我需要在编程等方面对断言更加自信。
答案 0 :(得分：6)
因此，Valgrind未能检测到您的堆损坏的明显原因是GCC STL实现完全没有发生损坏（即没有检测到错误）。
不幸的是，Valgrind的运行水平远低于STL，因此很多bug仍未被发现。例如：
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构建原始代码。它可能会遇到原始问题，并可能会遇到更多您尚未了解的问题。
答案 1 :(得分：0)
如果您在一台计算机上获得了良好的结果，而使用相同的工具在另一台计算机上获得了不良结果，那么在开发计算机上运行一些内存测试是个不错的主意。可以轻松获取memtest86的可启动映像，某些内存错误可以很好地解释您的问题。
另一方面，如果您在每台计算机上使用不同的操作系统，那么您正在使用的任何跨平台库的Windows版本中也可能存在（甚至更可能）错误。
答案 2 :(得分：0)
您不明白堆损坏是什么。特别是，内存泄漏不堆损坏。
Parallel Studio报告的内存泄漏也显得很虚假，并且更可能是Parallel Studio中的错误，而不是程序中的错误。