伙计们，可以请你推荐一个工具来发现内存损坏的生产multithreading服务器build立在C ++和Linux下的x86_64工作？ 我目前面临以下问题：每隔几个小时我的服务器崩溃与一个segfault和核心转储显示错误发生在malloc / calloc这肯定是内存损坏的迹象某处。
其实我已经尝试了一些没有太多运气的工具。 这是我迄今的经验：
Valgrind是一个伟大的（我甚至说最好的）工具，但它太慢，使服务器无法使用的生产。 我试图在舞台服务器上，它确实帮助我find一些内存相关的问题，但即使修复它们，我仍然在生产服务器上崩溃。 我在Valgrind下运行了我的舞台服务器好几个小时，但是仍然没有发现任何严重的错误。
据说ElectricFence是一个真正的记忆猪，但我甚至无法正常工作。 它几乎立即在舞台服务器上发生故障，在Valgrind根本没有显示任何问题的随机奇怪的地方。 也许ElectricFence不支持线程呢？我不知道。
DUMA – 与ElectricFence一样的故事，但更糟。 虽然EF生产核心转储与可读的backtraces DUMA只显示我“?????”（肯定服务器是用-g标志确定）
dmalloc – 我configuration服务器来使用它，而不是标准的malloc例程，但几分钟后挂起。 附加一个gdb的过程显示它挂在dmalloc的地方:(
我逐渐变得疯狂，根本不知道下一步该做什么。 我有以下工具可以尝试：mtrace，mpatrol，但也许有人有一个更好的主意？
我非常感谢在这个问题上的任何帮助。
更新：我设法find了错误的来源。 然而，我发现它在舞台服务器上没有生产使用helgrind / DRD / tsan – 在几个线程之间有一个datarace导致内存损坏。 关键是要使用适当的valgrind压制，因为这些工具显示太多的误报。 不过，我真的不知道如何在生产服务器上发现这种情况，而没有任何显着的减速。
是的，C / C ++内存损坏问题很难。 我也使用了几次valgrind，有时它显示了问题，有时不是。
虽然检查valgrind输出不会忽视其结果太快。 有时在经过相当长的时间之后，你会发现valgrind给了你一个线索，但你忽略了它。
另一个建议是比较以前已知的稳定版本的代码更改。 如果使用某种源版本控制系统（例如svn），这不是问题。 检查所有与内存相关的函数（例如，memcpy，memset，sprintf，new，delete / delete []）。
用gcc 4.1和-fstack-protector-all开关编译你的程序。 如果内存损坏是由堆栈粉碎引起的，应该可以检测到它。 您可能需要玩一些SSP的附加参数。
伙计们，我设法找到了错误的来源。 然而，我发现它在舞台服务器上使用helgrind / DRD / tsan – 有一个datarace之间的几个线程导致内存损坏。 关键是要使用适当的 valgrind压制，因为这些工具显示太多的误报。 不过，我真的不知道如何在生产服务器上发现这种情况，而没有任何显着的减速。
你试过了吗？ （向上滚动几行以查看可用选项）。
您可以尝试IBM净化，但我恐怕不是开源..
Google Perftools —开放源代码—可能有帮助，请参阅堆检查器文档。
试试这个： http ： //www.hexco.de/rmdebug/我广泛使用它，对性能的影响很小（它主要影响ram的数量），但是分配算法是一样的。 它总是被证明足以发现任何分配错误。 错误发生后，程序会立即崩溃，并且会有详细的日志。
我不确定它是否会抓住你的特定错误，但是MALLOC_CHECK_环境变量（ malloc手册页 ）在默认的Linux malloc实现中打开了额外的检查，并且通常没有显着的运行时间成本。