c++ - 跟踪生产 Linux 服务器上的内存损坏

Question

伙计们，您能否推荐一个用于在使用 c++ 构建并在 linux x86_64 下工作的生产多线程服务器上发现内存损坏的工具？我目前面临以下问题:每隔几个小时，我的服务器就会因段错误而崩溃，核心转储显示 malloc/calloc 中发生错误，这绝对是某处内存损坏的迹象。

实际上我已经尝试了一些工具，但运气不佳。以下是我目前的经验:

• Valgrind 是一个很棒的(我什至会说是最好的)工具，但它会大大降低服务器速度，使其无法在生产中使用。我在舞台服务器上尝试过，它确实帮助我找到了一些与内存相关的问题，但即使在修复它们之后，我仍然会在生产服务器上崩溃。我在 Valgrind 下运行了我的舞台服务器几个小时，但仍然没有发现任何严重的错误。

• ElectricFence 据说是一个真正的内存 pig ，但我什至无法让它正常工作。它几乎立即在舞台服务器上随机奇怪的地方出现段错误，而 Valgrind 根本没有显示任何问题。也许 ElectricFence 不支持线程？...我不知道。

• DUMA - 与 ElectricFence 相同，但更糟糕。虽然 EF 生成了带有可读回溯的核心转储，但 DUMA 只向我显示“?????”(是的，服务器肯定是使用 -g 标志构建的)

• dmalloc - 我将服务器配置为使用它而不是标准的 malloc 例程，但是它在几分钟后挂起。将 gdb 附加到进程表明它卡在 dmalloc 的某个位置:(

我逐渐变得疯狂，根本不知道下一步该做什么。我有以下工具可供尝试:mtrace、mpatrol 但也许有人有更好的主意？

非常感谢您对此问题的任何帮助。

更新:我设法找到了错误的根源。但是，我在舞台服务器上发现它不是使用 helgrind/DRD/tsan 的生产服务器 - 多个线程之间存在数据竞争，导致内存损坏。关键是使用适当的 valgrind 抑制，因为这些工具显示了太多的误报。仍然我真的不知道如何在生产服务器上发现这一点而没有任何明显的减速......

Answer 1

是的，C/C++ 内存损坏问题非常棘手。我也使用了几次valgrind，有时它会显示问题，有时不会。

在检查 valgrind 输出时，不要太快地忽略它的结果。有时在花费相当长的时间后，你会发现 valgrind 一开始就给了你线索，但你忽略了它。

另一个建议是比较以前已知稳定版本的代码更改。如果您使用某种源版本控制系统(例如 svn)，这不是问题。检查所有与内存相关的函数(例如 memcpy、memset、sprintf、new、delete/delete[])。