伙计们，您能否推荐一种工具，用于在使用c ++构建并在linux x86_64下工作的生产多线程服务器上发现内存损坏？我目前面临以下问题：每隔几个小时，我的服务器崩溃并出现段错误，核心转储显示错误发生在malloc / calloc中，这绝对是内存在某处被破坏的迹象。
实际上我已经尝试了一些没有太多运气的工具。以下是我迄今为止的经历：
Valgrind是一个很棒的（我甚至说是最好的）工具，但它会使服务器运行速度过慢，使其在生产中无法使用。我在舞台服务器上尝试了它，它确实帮助我找到了一些与内存相关的问题，但即使在修复它们之后，我仍然会在生产服务器上崩溃。我在Valgrind下运行了我的舞台服务器几个小时，但仍然无法发现任何严重的错误。
ElectricFence据说是一个真正的记忆力猪，但我甚至无法让它正常工作。它几乎立即在舞台服务器上的随机奇怪的地方发生了段落，而Valgrind根本没有表现出任何问题。也许ElectricFence不支持线程化？我不知道。
DUMA - 和ElectricFence一样，但更糟糕的是。虽然EF产生了具有可读回溯的核心转储，但DUMA只显示“?????”（并且肯定服务器使用-g标志构建）
dmalloc - 我将服务器配置为使用它而不是标准的malloc例程，但它会在几分钟后挂起。将gdb附加到进程显示它挂在dmalloc中的某处：（
我渐渐变得疯狂，根本不知道接下来该做什么。我有以下工具可供尝试：mtrace，mpatrol但也许有人有更好的想法？
我非常感谢有关这个问题的任何帮助。
更新：我设法找到错误的来源。但是我发现它在舞台服务器上没有生成一个使用helgrind / DRD / tsan - 几个线程之间有一个datarace导致内存损坏。关键是使用适当的valgrind抑制，因为这些工具显示太多的误报。我仍然不知道如何在生产服务器上发现这种情况而不会出现任何明显的减速......
答案 0 :(得分：7)
是的，C / C ++内存损坏问题很严重。 我也曾多次使用过valgrind，有时它会发现问题而有时候却没有。
在检查valgrind输出时，不要太快地忽略其结果。有时候花了相当长的时间后，你会发现valgrind首先给你了解线索，但是你忽略了它。
另一个建议是比较以前已知的稳定版本的代码更改。如果您使用某种源版本控制系统（例如svn），这不是问题。检查所有与内存相关的功能（例如memcpy，memset，sprintf，new，delete / delete []）。
答案 1 :(得分：6)
使用gcc 4.1和-fstack-protector-all开关编译程序。如果内存损坏是由堆栈粉碎引起的，那么应该能够检测到它。您可能需要使用SSP的一些其他参数。
答案 2 :(得分：4)
伙计们，我设法找到了这个bug的来源。但是我在舞台服务器上使用helgrind / DRD / tsan发现它 - 在几个线程之间存在一个datarace导致内存损坏。关键是使用正确的 valgrind抑制，因为这些工具显示了太多的误报。我仍然不知道如何在生产服务器上发现这种情况而不会出现任何明显的减速......
答案 3 :(得分：3)
你试过-fmudflap吗？ （向上滚动几行以查看可用选项）。
答案 4 :(得分：1)
你可以尝试IBM净化，但我担心这不是开源..
答案 5 :(得分：1)
Google Perftools ---这是开源的 - 可能会有所帮助，请参阅heap checker文档。
答案 6 :(得分：1)
试试这个： http://www.hexco.de/rmdebug/ 我广泛使用它，它对性能的影响很小（它主要影响ram的数量），但分配算法是相同的。它总是被证明足以找到任何分配错误。一旦发生错误，您的程序就会崩溃，并且会有详细的日志。
答案 7 :(得分：1)
我不确定它是否会捕获您的特定错误，但MALLOC_CHECK_环境变量（malloc man page）会在默认的Linux malloc实现中启用其他检查，通常没有显着的运行时成本。