7

将项目从 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

有没有更好的方法来找出真正导致内存泄漏的原因？

4

6 回答 6

9

此内存泄漏是由 Delphi 错误引起的，QC #67709

上次 Delphi 2009 更新修复了它，难怪我无法修复它。

于 2009-06-03T12:01:42.153 回答
7

只要泄漏的内存块的大小不会随着您的程序使用的时间越长/越多而增长，那么它就不是问题。如果您有长期存在的对象，这些对象仅在您终止应用程序时才被释放，这与您泄露它们一样 - 所有内存在终止时被回收（当然，除非它们处理内存之外的资源）。

您要关注的内存泄漏是随着时间或使用而累积的内存泄漏。如果每次都是 20 个字节，那么不要担心。

于 2008-11-07T18:01:49.383 回答
1

我不知道 D2009 VCL 中是否有任何泄漏，因此假设您的代码中有泄漏，首先我会检查以下内容：

  • 是否有任何以该表单创建的数组或列表（因为@DynArraySetLength）在您处理表单时未释放。
  • 是否有任何函数可以创建并返回一些应该由外部调用者释放的对象，如果你有这种函数，请检查调用者是否释放了该对象。
  • 如果这没有显示泄漏，那么您应该检查您在表单代码中创建的每个对象是否在您销毁表单时被销毁。
于 2008-11-07T15:12:13.050 回答
1

上次我在这些方面遇到令人费解的泄漏时，我查看了违规对象的原始内存 - 并看到了向我显示它是哪种数据的文本。当它说它不知道它是什么类型的对象时，这可能意味着它首先不是一个对象——所以看看动态分配的东西，包括字符串。

于 2009-06-02T03:53:58.593 回答
0

IIRC VCL 有一些像这样的非常小的泄漏，您可以忽略而不必担心。这可能是其中之一！？希望有人澄清这一点。

于 2008-11-07T12:54:24.030 回答
0

我会说您的 Form OnCreate 事件处理程序中发生了一些事情，该处理程序正在增长 DynArray。
并且最后没有发布 DynArray。
但是，如果没有看到代码并使用 FastMM 实际调试它，几乎不可能猜测到底发生了什么。

于 2008-11-07T19:08:34.117 回答