小编gla*_*lig的帖子

我首先查找了现有的答案,并看到Valgrind是每个人最喜欢的linux上内存泄漏调试工具.不幸的是,Valgrind似乎并不适用于我的目的.我会尽力解释原因.

约束:

• 泄漏仅在客户的环境中重现.由于某些法律限制,我们必须使用现有的二进制文件.没有重建.
• 在常规环境中,我们的应用程序消耗大约10%的CPU.说,我们可以容忍高达10倍的CPU使用量增加.使用默认memcheck 设置的Valgrind会使我们的应用程序长时间无响应.

我需要的是相当于Microsoft的UMDH:打开每个堆分配的堆栈跟踪,然后在某个时间点转储按堆栈分组的所有分配,并按分配计数按降序排序.我们的应用程序在Windows和Linux平台上提供,因此我知道在UMDH下的Windows上的性能仍然可以容忍.

以下是我考虑的工具/方法

• Valgrind的-memcheck和-massif工具它们做的远远超过了需要(比如为每个分配指针扫描整个进程内存),它们太慢了,它们仍然没有完全按照我的
  需要执行(转储按计数排序的callstack) ,所以我将编写一些解析输出的脚本
• dmalloc库(dmalloc.com)需要新的二进制文件
• LeakTracer(http://www.andreasen.org/LeakTracer/)仅适用于C++ new/delete(我也需要malloc/free),没有逐个堆栈和排序功能
• 使用LD_PRELOAD机制将自己实现为.so库(使用LD_PRELOAD机制覆盖'malloc')至少需要一周的时间,因为我的Linux编码技能,并且感觉就像发明了一辆自行车.

我错过了什么吗？是否有任何轻量级Valgrind选项或现有的LD_PRELOAD工具？

我观察到Microsoft实现的一个有趣的问题strncat.它接触源缓冲区之外的1个字节.请考虑以下代码:

#include <stdio.h>
#include <stdlib.h>
#include <memory.h>
#include <string.h>

void main()
{
    char dstBuf[1024];
    char* src = malloc(112);
    memset(src, 'a', 112);
    dstBuf[0] = 0;
    strncat(dstBuf, src, 112);
}

strncat112字节块后读取1个字节.因此,如果您不幸在无效页面边界上进行分配,则应用程序崩溃.大型应用程序可能会在这些地方间歇性地崩溃.(请注意,可以使用gflags PageHeap设置模拟此类条件;块大小必须能够被指针大小整除才能正确对齐.)

这是预期的行为还是错误？任何确认的链接？(我阅读了几个描述,strncat但它们可以通过两种方式解释,具体取决于你最初的想法......)

更新(回答有关证据的问题):如果从上面的文字中不清楚,我道歉,但这是一个实验性的事实.我在strncat读取地址src + srcBufSize 的应用程序中观察到间歇性崩溃.在这个小例子中,gflags PageHeap在崩溃时运行一致(100%).所以据我所知,证据非常可靠.

Update2(编译器信息)MS Visual Studio 2005版本8.0.50727.867.构建平台:64位版本(32位无repro).用于重现崩溃的操作系统:Windows Server 2008 R2.

更新3此问题还使用MS Visual Studio 2012 11.0.50727.1中内置的二进制文件重现

更新4 链接以在Microsoft Connect上发布 ; 链接到MSDN论坛上的讨论

更新5问题将在下一个VS版本中修复.旧版本没有计划修复.请参阅上面的"Microsoft Connect"链接.