FastMM突然报告Graphics32内存泄漏

发布于 2024-10-10 13:08:35 字数 431 浏览 5 评论 0原文

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

度的依靠╰つ 2024-10-17 13:08:35

如果您使用完整版本的 FastMM4，请启用 FullDebugMode。还可以打开详细的映射生成来帮助进行堆栈跟踪。检查该单元的单元初始化部分，看看是否存在任何问题。

回复收藏 0 原文

许仙没带伞 2024-10-17 13:08:35

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

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

另请参阅这篇文章了解更多提示。

编辑：

一个好的第一步是在您的 .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 涉及您的泄漏。
从那里，您可以开始调试以找出泄漏的原因。

——杰罗恩

Compile your app with full debug info, then in the linker options, make sure your debug info is in the .EXE and/or .MAP file.

Then run FastMM with FullDebugMode, and copy/paste the resulting .TXT file in your question.

See also this post for more tips.

Edit:

A good first step is to do something like this on your .TXT file:

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

That gives you the first allocation number, in your case 281.

From that, you search in the .TXT for the allocation number:

--------------------------------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

Here you can see, that the NewRegistry is involved in your leak.
From there, you can start debugging to find out why it leaks.

--jeroen

回复收藏 0 原文