如何使用 fastMM 追踪棘手的内存泄漏？
将项目从 Delphi 2007 升级到 Delphi 2009 后，我遇到了未知的内存泄漏，到目前为止，我一直在尝试使用 fastMM 来跟踪它，这是 fastMM 堆栈跟踪报告的内容：
A memory block has been leaked. The size is: 20
This block was allocated by thread 0x111C, and the stack trace (return addresses)
at the time was:
40339E [System.pas][System][@GetMem][3412] 534873 [crtl][_malloc]
56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918]
56D316 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3961]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
562D48 [DBCommon.pas][DBCommon][TFilterExpr.PutExprNode][1583]
408E46 [System.pas][System][DynArraySetLength][20464]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
408E92 [System.pas][System][@DynArraySetLength][20486]
528C1B [Forms.pas][Forms][TCustomForm.DoCreate][3260]
171A1A [GetRawStackTrace]
The block is currently used for an object of class: Unknown
The allocation number is: 302844
有时我会得到以下信息：
A memory block has been leaked. The size is: 20
This block was allocated by thread 0x111C, and the stack trace (return addresses)
at the time was:
40339E [System.pas][System][@GetMem][3412]
534873 [crtl][_malloc]
56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918]
56D316 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3961]
77DC921A [RtlAnsiStringToUnicodeString]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
7726B8F5 [GetProcAddress]
7726B907 [GetProcAddress]
589B1E [ossrv.cpp][MidasLib][DllGetDataSnapClassObject][3163]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
408E92 [System.pas][System][@DynArraySetLength][20486]
The block is currently used for an object of class: Unknown
是否有一些更好的方法来找出真正导致内存泄漏的原因？
After upgrading a project from Delphi 2007 to Delphi 2009 I'm getting an Unknown memory leak, so far I've been tryin to track it down using fastMM, here is what fastMM stack trace reports:
A memory block has been leaked. The size is: 20
This block was allocated by thread 0x111C, and the stack trace (return addresses)
at the time was:
40339E [System.pas][System][@GetMem][3412] 534873 [crtl][_malloc]
56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918]
56D316 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3961]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
562D48 [DBCommon.pas][DBCommon][TFilterExpr.PutExprNode][1583]
408E46 [System.pas][System][DynArraySetLength][20464]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
408E92 [System.pas][System][@DynArraySetLength][20486]
528C1B [Forms.pas][Forms][TCustomForm.DoCreate][3260]
171A1A [GetRawStackTrace]
The block is currently used for an object of class: Unknown
The allocation number is: 302844
And sometimes I get this:
A memory block has been leaked. The size is: 20
This block was allocated by thread 0x111C, and the stack trace (return addresses)
at the time was:
40339E [System.pas][System][@GetMem][3412]
534873 [crtl][_malloc]
56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918]
56D316 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3961]
77DC921A [RtlAnsiStringToUnicodeString]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
7726B8F5 [GetProcAddress]
7726B907 [GetProcAddress]
589B1E [ossrv.cpp][MidasLib][DllGetDataSnapClassObject][3163]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
408E92 [System.pas][System][@DynArraySetLength][20486]
The block is currently used for an object of class: Unknown
Is there some better way to figure out what really is causing the Memory leak?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
此内存泄漏是由 Delphi bug 引起的，QC #67709
它上次的 Delphi 2009 更新已修复该问题，难怪我无法修复它。
This memory leak was being caused by a Delphi bug, QC #67709
It was fixed by the last Delphi 2009 update, no wonder I wasn't able to fix it.
只要泄漏的内存块的大小不会随着程序使用的时间越长/越多而增加，那么就不需要担心。 如果您有长期存在的对象，并且仅在终止应用程序时才释放它们，则与泄漏它们一样 - 所有内存都会在终止时回收（当然，除非它们处理超出内存的资源）。
您想要关注的内存泄漏是随着时间或使用而累积的内存泄漏。 如果每次都是 20 字节，那就不用担心了。
As long as the size of the memory block leaked does not grow the longer/more your program is used, then it isn't a concern. If you have long lived objects that are only freed when you terminate the application it is the same as if you leaked them - all memory is reclaimed on termination (Unless of course they have handles resources beyond memory).
The memory leaks you want to be concerned with are the ones that accumulate over time or usage. If it is 20 bytes everytime then don't sweat it.
我不知道 D2009 VCL 中是否存在任何泄漏，因此假设您的代码中存在泄漏，首先我会检查以下内容：
@DynArraySetLength）当您处置表单时不会释放该表单。I don't know if there are any leaks in D2009 VCL, so presuming leak is in your code, first I would check following:
@DynArraySetLength) created in that form that is not released when you dispose form.上次我遇到令人费解的泄漏时，我查看了有问题的对象的原始内存，并看到了向我显示它是什么类型的数据的文本。 当它说它不知道它是什么类型的对象时，很可能意味着它首先不是一个对象——所以看看动态分配的东西，包括字符串。
The last time I had a puzzling leak along these lines I looked over the raw memory of the offending object--and saw text that showed me what sort of data it was. When it says it doesn't know what sort of object it is that likely means it isn't an object in the first place--so look at dynamically allocated things, including strings.
IIRC VCL 有一些像这样的非常小的泄漏，您可以忽略它而不必担心。 这可能就是其中之一！？ 希望有人澄清这一点。
IIRC VCL had a few very small leaks like this that you can ignore without much worry. This might be one of them!? Hope somebody clarifies this point.
我想说的是，您的 Form OnCreate 事件处理程序中发生了一些正在增长 DynArray 的事情。
并且 DynArray 最终没有被释放。
但如果没有看到代码并使用 FastMM 实际调试它，几乎不可能猜测到底发生了什么。
I would say you have something happening in your Form OnCreate event handler that is growing a DynArray.
And that DynArray is not released at the end.
But without seeing the code and actually debugging it with FastMM, it's close to impossible to guess what's really happening.