FastMM 突然报告 Graphics32 内存泄漏答案

【问题标题】：FastMM suddenly reports memory leaks in Graphics32FastMM 突然报告 Graphics32 内存泄漏
【发布时间】：2011-01-07 16:25:19
【问题描述】：

我有一个空项目（它只包含一个表单）。如果我将此行添加到项目'USES GR32_Image;'并运行应用程序，FastMM 在程序中显示泄漏。 FastMM 设置为完全调试。我的程序中没有代码 - 除了 Delphi IDE 生成的代码和“使用 gr32”行。

报告毫无意义。这是完整的日志：http://pastebin.com/Yhev3rJ2
这里是源代码：http://pastebin.com/VjRrRiS8

我以前使用过 Graphics32 单元，从来没有遇到过问题。为什么我有这个泄漏以及为什么 FastMM 无法生成正确的报告？

【问题讨论】：

您能否发布您的代码以便我们提供帮助。您应该能够将一些东西放在一个会出现问题的单个 .dpr 文件中。
@Altar 为什么没有在堆栈跟踪中获取函数名称？我认为您需要正确配置 FastMM。另外，我刚刚想到这些内存泄漏可能是 VCL 的预期泄漏。
@David：看起来 FullDebugMode 已打开并且 FastMM 配置正确，但它没有映射文件来查找地址。如果他让链接器生成详细的地图文件，事情就会变得更加清晰。
只是将您正在谈论的文件添加到项目中不会导致内存泄漏。至少没有使用最新版本，我下载并尝试了它。你确定是 Graphics32 造成的吗？是的，TFunctionRegistry 是 Graphics32 的一部分，但这可能只是意味着您的代码正在泄漏。 GR32_Image 中没有初始化部分。请按照 Mason 的建议做，Project Options->Linker->Map File Details (BDS2006)。
@altar 是 gr32 在 dpr 中使用 fastmm 之前还是之后使用的？

标签： delphi fastmm

【解决方案1】：

如果您使用完整版 FastMM4，请启用 FullDebugMode。还打开详细的地图生成以帮助堆栈跟踪。检查该单元的单元初始化部分，看看是否有任何问题。

【讨论】：

【解决方案2】：

使用完整的调试信息编译您的应用，然后在链接器选项中，确保您的调试信息位于 .EXE 和/或 .MAP 文件中。

然后使用 FullDebugMode 运行 FastMM，并将生成的 .TXT 文件复制/粘贴到您的问题中。

有关更多提示，另请参阅this post。

编辑：

第一步是对您的 .TXT 文件执行类似的操作：

find "The allocation number is" < fastmmlog.txt | sort /R

这为您提供了第一个分配编号，在您的情况下为 281。

由此，您在 .TXT 中搜索分配号：

--------------------------------2011/1/7 23:31:03--------------------------------
A memory block has been leaked. The size is: 20

This block was allocated by thread 0x1540, and the stack trace (return addresses) at the time was:
402D80 [System][System][@GetMem]
40388F [System][System][TObject.NewInstance]
403C12 [System][System][@ClassCreate]
4038C4 [System][System][TObject.Create]
403C12 [System][System][@ClassCreate]
403C6A [System][System][@AfterConstruction]
457922 [GR32_Bindings][GR32_Bindings][NewRegistry]
45807E [GR32_LowLevel][GR32_LowLevel][RegisterBindings]
458152 [GR32_LowLevel][GR32_LowLevel][GR32_LowLevel]
404373 [System][System][InitUnits]
4043DB [System][System][@StartExe]

The block is currently used for an object of class: TList

The allocation number is: 281

在这里您可以看到，NewRegistry 与您的泄漏有关。
从那里，您可以开始调试以找出泄漏的原因。

--杰罗恩

【讨论】：

嗨，杰罗恩。我就是这么做的。请看原帖。我不得不从日志中删除很大一部分，因为帖子限制为 30000 个字符。
将您的完整 .txt 放在网上 pastebin.com 或 gist.github.com 以便人们查看完整内容。
我粘贴了完整的日志和源代码。请尽可能查看原帖。
已接受答案（它回答了“为什么 FastMM 无法生成正确的报告”问题）。谢谢！

【解决方案3】：

两个问题都解决了。

我记得前段时间我在 GR32.inc 中添加了这行代码： {$D-} 我删除了该行，重新编译了 VCL 并且它起作用了。完全是我的错。
查看 Jeroen Pluimers 的帖子，该帖子回答了“为什么 FastMM 无法生成正确的报告？”的问题

感谢大家的参与。

【讨论】：

很高兴听到您已排序，但您可以将代表交给您以外的其他人！
您只有 cmets，没有独立的答案。据我所知，我不能投票评论作为问题的解决方案。对不起。
我知道，但我并不是说我应该得到代表。其他人也赚到了，我看到你现在已经把它给了杰罗恩。另外，您的 IMAGE_LARGE_ADDRESS_AWARE 问题是否得到了您所需要的信息？