Delphi 调用FastMM4 LogAllocatedBlocksToFile（）是否会定期占用内存空间？

我在一个Delphi5程序中寻找一个难以捉摸的内存问题，在这个程序中，内存会在客户站点被随机覆盖。在尝试了很多没有结果的事情之后，我现在想使用LogAllocatedBlocksToFile的FastMM4输出来找出在覆盖区域之前分配了哪些对象。程序使用计时器每30分钟将分配的块信息写入一个新文件。不幸的是，我的程序调试构建的测试运行在大约23小时后崩溃，出现了一个OutofMemory异常，根据MadExcept，使用了分配的1.83GB内存

从SysInternals Process Explorer中，每次调用LogAllocatedBlocksToFile都会分配内存，但不会释放内存：

CPU使用率图中的红色尖峰是LogAllocatedBlocksToFile调用。我在之前和之后添加了对LogMemoryManager StateToFile的调用，私有字节的最后一个峰值的数据从183MB增加到218MB，如下所示：

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

这是：

已分配55055K 47910K间接费用 53%的效率

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

我使用的是FastMM4的4.991版，今天从SourceForge下载。测试程序在调试模式下运行，并设置以下定义：

全调试模式

使用CustomFixedSizeOverroutines 使用CustomVariableSizeOverroutines NoDebugInfo ASM版本 卸载后检测操作 拉瓦斯塔克痕迹 日志错误文件 LogMemoryLeakDetailToFile 一直都是位置门 SuppressFreeMemErrorsInsideException EnableMemoryLeakReporting HideExpectedLeaksRegisteredByPointer 泄漏报告所需的BuggerPresence 启用MX ForceMMX 启用BackwardCompatibleMsharing UseOutputDebugString

问题:

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

简短版本：

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

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

长版本：

该项目最初使用的是FastMM4的旧版本4.97，我在这里将其与支持库文件版本1.44.0.4、产品版本1.42一起签入

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

自从在那里复制并重新启动应用程序后，问题似乎消失了。调用LogAllocatedBlocksToFile时，内存使用不会增加

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

---

关于调试…

我在源代码中看不到任何可能导致此类问题的内容。你能把你设定的定义列表也放进去吗？@graymart:我一回到办公室就可以了，测试系统将于周三开始-对不起。如果内存被随机覆盖，也许你会更幸运地使用它？！您没有指定内存覆盖是否会导致异常。如果他们不这样做，恐怕gFlags不是一个选择。如果他们这样做了，值得一试。我很好奇，你是怎么知道内存被覆盖的？@Graymatter:我已经在我的问题中添加了信息。@LievenKeersmaekers:内存覆盖很容易注意到，它们经常修改在UI中可见或写入数据文件的字符串。如果字符串数据被覆盖，它是相对良性的，但是当引用计数或字符串长度被修改时，程序中迟早会出现异常。我还不能确定这些覆盖的来源。字符串数据应该是不可变的，但我无法使写入这些内存位置的硬件断点工作。