3

我正在寻找一个 Delphi 5 程序中难以捉摸的内存问题，其中内存在客户站点被随机覆盖。在尝试了很多到目前为止都没有结果的事情之后，我现在想使用 FastMM4 的输出LogAllocatedBlocksToFile()来找出在被覆盖区域之前立即分配了哪些对象。该程序使用计时器每 30 分钟将分配的块信息写入一个新文件。不幸的是，我的程序测试运行（DEBUG 构建）在大约 23 小时后崩溃，EOutOfMemory但根据 MadExcept 使用分配的 1.83 GB 内存。

从 SysInternals Process Explorer 看起来，每次调用都LogAllocatedBlocksToFile()分配但不释放内存：

Process Explorer 的 100 分钟程序运行屏幕截图

CPU 使用情况图中的红色尖峰是LogAllocatedBlocksToFile()调用。我在LogMemoryManagerStateToFile()之前和之后添加了调用，最后一个峰值的数据（私有字节从大约 183 MB 增加到大约 218 MB）如下所示：

55054K 分配
47911K 开销
53% 效率

和这个：

55055K 分配
47910K 开销
53% 效率

因此，根据 Process Explorer，FastMM4 似乎不知道程序消耗的额外内存。

我使用的是今天从 SourceForge 下载的 FastMM4 版本 4.991。测试程序在 DEBUG 模式下运行，具有以下定义集：

全调试模式

UseCustomFixedSizeMoveRoutines
UseCustomVariableSizeMoveRoutines
NoDebugInfo
ASMVersion
DetectMMOperationsAfterUninstall
RawStackTraces
LogErrorsToFile
LogMemoryLeakDetailToFile
AlwaysAllocateTopDown
SuppressFreeMemErrorsInsideException
EnableMemoryLeakReporting
HideExpectedLeaksRegisteredByPointer
RequireDebuggerPresenceForLeakReporting
EnableMMX
Use ForceMMX
EnableBackwardCompatibleMMSha

问题：

这些功能是否有任何已知问题？我是否没有正确使用它们，是否不打算在一个调试会话中多次调用它们？有没有办法再次释放该内存？

4

1 回答 1

7

精简版：

我发现这是支持库的版本不匹配FastMM_FullDebugMode.dll。

旧版本的库与编译到可执行文件中的新版本一起使用。似乎没有检查版本是否匹配。但是，模块在运行时并不能真正协同工作。

长版：

该项目最初使用的是 FastMM4 的旧版本 4.97，我在此处与支持库（文件版本 1.44.0.4，产品版本 1.42）一起签入。

在尝试查找程序中的错误时，我已将 FastMM4 升级到版本 4.991。我还记得将新的支持库（文件版本 1.61.0.6，产品版本 1.60）复制到构建目录。但是，一段时间后我一定是从目录中删除了它，或者我将它复制到错误的目录中，因为两个小时前我检查了应用程序加载的模块，发现应用程序已经选择了旧版本的来自另一个目录的支持库，因为它不在构建目录中。

由于将其复制到那里并重新启动应用程序，问题似乎就消失了。LogAllocatedBlocksToFile()调用时内存使用量不会增加。

也许这对某人有帮助，所以我回答这个问题而不是删除问题。

在调试...

于 2014-03-19T19:10:59.143 回答