pac*_*nga 15 c++ linux memory production corruption
大家好吗,请你推荐一个工具,用于在使用c ++构建并在linux x86_64下工作的生产多线程服务器上发现内存损坏？我目前面临以下问题:每隔几个小时我的服务器崩溃并出现段错误,核心转储显示错误发生在malloc/calloc中,这绝对是内存在某处被破坏的标志.
实际上我已经尝试了一些没有太多运气的工具.这是我迄今为止的经历:
Valgrind是一个伟大的(我甚至说是最好的)工具,但它使服务器的速度变慢,使其无法在生产中使用.我在舞台服务器上尝试了它,它确实帮助我找到了一些与内存相关的问题但是即使在修复它们之后我仍然会在生产服务器上崩溃.我在Valgrind下运行了我的舞台服务器几个小时,但仍然无法发现任何严重的错误.
据说ElectricFence是一个真正的记忆猪,但我甚至无法让它正常工作.它几乎立即在舞台服务器上的随机奇怪的地方进行了段落,其中Valgrind根本没有显示任何问题.也许ElectricFence不支持线程化？我不知道.
杜马 - 和ElectricFence一样,但更糟糕的是.虽然EF产生了具有可读回溯的核心转储,但DUMA只显示"?????"(并且肯定服务器使用-g标志构建)
dmalloc - 我将服务器配置为使用它而不是标准的malloc例程,但它会在几分钟后挂起.将gdb附加到进程显示它挂在dmalloc中的某处:(
我渐渐变得疯狂,根本不知道接下来该做什么.我有以下工具要尝试:mtrace,mpatrol但也许有人有更好的主意？
我非常感谢你对这个问题的任何帮助.
更新:我设法找到了错误的来源.但是我发现它在舞台服务器上没有生成一个使用helgrind/DRD/tsan - 几个线程之间有一个datarace导致内存损坏.关键是使用适当的valgrind抑制,因为这些工具显示太多的误报.我仍然不知道如何在没有任何显着减速的情况下在生产服务器上发现这一点......
是的,C/C++内存损坏问题很严重.我也曾多次使用过valgrind,有时它会发现问题而有时候没有.
在检查valgrind输出时,不要过于忽略其结果.有时经过相当长的一段时间后,你会发现valgrind首先给你了解线索,但是你忽略了它.
另一个建议是比较以前已知的稳定版本的代码更改.如果您使用某种源版本控制系统(例如svn),这不是问题.检查所有与内存相关的功能(例如memcpy,memset,sprintf,new,delete/delete []).
伙计们，我设法找到了错误的根源。但是我在使用 helgrind/DRD/tsan 的舞台服务器上发现了它 - 多个线程之间存在数据争用，导致内存损坏。关键是使用适当的valgrind 抑制，因为这些工具显示出太多误报。我仍然不知道如何在生产服务器上发现这一点而不会出现任何明显的减速......
| 归档时间： |
|
| 查看次数： |
7551 次 |
| 最近记录： |