在Delphi 5程序中,我正在寻找一个难以捉摸的记忆问题,在这个程序中,内存被随机覆盖在客户站点上。在尝试了很多没有结果的事情之后,我现在想使用来自FastMM4的LogAllocatedBlocksToFile()
输出来找出在覆盖区域之前分配了哪些对象。该程序使用计时器每30分钟将分配的块信息写入新文件。不幸的是,我的程序测试运行(调试构建)在23小时后崩溃,但有一个EOutOfMemory
异常,根据MadExcept分配的内存为1.83GB。
在SysInternals Process中,看起来每个LogAllocatedBlocksToFile()
调用都分配,但没有释放内存:
CPU使用率图中的红色尖峰是LogAllocatedBlocksToFile()
调用。我在前面和之后添加了对LogMemoryManagerStateToFile()
的调用,最后一个峰值的数据(私有字节从大约183 MB增加到大约218 MB)如下所示:
55054K拨款 47911 K间接费用 效率53%
这是:
55055 K分配 47910K间接费用 效率53%
因此,根据Process,FastMM4似乎不知道程序所消耗的额外内存。
我使用的是今天从FastMM4下载的4.991版的SourceForge。测试程序在调试模式下运行,具有以下定义集:
FullDebugMode UseCustomFixedSizeMoveRoutines UseCustomVariableSizeMoveRoutines NoDebugInfo ASMVersion DetectMMOperationsAfterUninstall RawStackTraces LogErrorsToFile LogMemoryLeakDetailToFile AlwaysAllocateTopDown SuppressFreeMemErrorsInsideException EnableMemoryLeakReporting HideExpectedLeaksRegisteredByPointer RequireDebuggerPresenceForLeakReporting EnableMMX ForceMMX EnableBackwardCompatibleMMSharing UseOutputDebugString
问题:
这些功能有什么已知的问题吗?我是否没有正确地使用它们,它们是否不打算在一个调试会话中被多次调用?有什么办法让记忆再次释放吗?
发布于 2014-03-19 11:10:59
简写版:
我发现这是支持库FastMM_FullDebugMode.dll
的版本错配。
库的旧版本与编译到可执行文件中的更新版本一起工作。似乎没有检查版本是否匹配。但是,模块在运行时并不能真正协同工作。
长版本:
该项目最初使用的是FastMM4的较旧版本4.97,我在这里与支持库(文件版本1.44.0.4,产品版本1.42)一起签入了该版本。
在试图查找程序中的漏洞时,我已经将FastMM4升级到4.991版。我还记得将新的支持库(文件版本1.61.0.6,产品版本1.60)复制到构建目录中。然而,一段时间后,我必须将其从目录中删除,否则我首先将其复制到错误的目录中,因为两个小时前,我检查了应用程序加载的模块,发现应用程序从另一个目录中获取了支持库的旧版本,因为它不在构建目录中。
由于复制到那里并重新启动应用程序,问题似乎消失了。当调用LogAllocatedBlocksToFile()
时,内存使用量不会增加。
也许这对某人有帮助,所以我回答这个问题,而不是删除这个问题。
继续调试..。
https://stackoverflow.com/questions/22461755
复制相似问题