Question

我有CodeGear C ++ Builder XE5。使用TIdTCPServer创建的服务器，运行良好。但是，服务使用的内存正在增长。我终于设法包括完整版的FastMM4内存管理器，在摆弄了选项之后，我发现内存泄漏的确认：

13 - 20 bytes: TIdThreadSafeInteger x 1
21 - 36 bytes: TIdCriticalSection x 2, Unknown x 1
53 - 68 bytes: UnicodeString x 1
85 - 100 bytes: Unknown x 21
149 - 164 bytes: Unknown x 21
181 - 212 bytes: Unknown x 2

显然x1和x2不关心我，但是x21泄漏很糟糕，因为这是高度使用的服务 - 每个连接都会出现100和164字节：

更多细节信息说明：

A memory block has been leaked. The size is: 100

This block was allocated by thread 0xD98, and the stack trace (return addresses) at the time was:
    8D4743 [Unknown function at @@Zip_int@Finalize]
    8D461D [Unknown function at @@Zip_int@Finalize]
    8E0F94 [Unknown function at @@Zip_int@Finalize]
    8E0F59 [Unknown function at @@Zip_int@Finalize]
    8DFADA [Unknown function at @@Zip_int@Finalize]
    8DE722 [Unknown function at @@Zip_int@Finalize]
    8BF045 [Unknown function at @@Searchfilelist@Finalize]
    8C4C90 [Unknown function at @@Searchfilelist@Finalize]
    8D6638 [Unknown function at @@Zip_int@Finalize]
    775D1C77 [Unknown function at RtlNtStatusToDosErrorNoTeb]
    452A45 [@Fastmm4@DebugGetMem$qqri]

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

A memory block has been leaked. The size is: 164

This block was allocated by thread 0x5394, and the stack trace (return addresses) at the time was:
    8D4743 [Unknown function at @@Zip_int@Finalize]
    8D461D [Unknown function at @@Zip_int@Finalize]
    8E0FD9 [Unknown function at @@Zip_int@Finalize]
    8E0F59 [Unknown function at @@Zip_int@Finalize]
    8DFADA [Unknown function at @@Zip_int@Finalize]
    8DE722 [Unknown function at @@Zip_int@Finalize]
    8BF045 [Unknown function at @@Searchfilelist@Finalize]
    8C4C90 [Unknown function at @@Searchfilelist@Finalize]
    8D6638 [Unknown function at @@Zip_int@Finalize]
    775D1C77 [Unknown function at RtlNtStatusToDosErrorNoTeb]
    452A45 [@Fastmm4@DebugGetMem$qqri]

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

The allocation number is: 125893

此时我被卡住了，因为我没有直接打电话，所以我不知道这是哪里来的 Zip_int。有人能指出我正确的方向吗？

Answer 1

前两个泄漏 - TIdThreadSafeInteger和TIdCriticalSection - 是众所周知的Indy漏洞，只有在app关闭时才会发生，因为它们是故意不释放的全局对象。我很惊讶在泄漏报告中看到它们，因为Indy将它们作为已知的泄漏注册到FastMM。

其他人不是Indy泄漏。你的代码必须分配一些你不能解放的东西。 UnicodeString泄漏可能表明这一点，因为泄漏String的最常见方式是它是否是未释放的类实例的成员。如果泄漏与服务器接收的连接数成比例，那么您可能会分配一些内容并将其存储在TIdContext中，例如在OnConnect事件中，而不是在以后释放，例如OnDisconnect事件。但是你没有显示你的代码。

我觉得很奇怪的是泄漏似乎是在单元定稿期间分配的，而不是在应用程序的正常运行期间，但为什么会有这么多Finalize个调用，我不知道。除非应用程序的堆栈跟踪信息错误。 FastMM无法报告更有意义的信息，因为这些单元可能未在启用调试信息的情况下进行编译。你至少有一个编译器为你的应用程序生成的.MAP文件吗？这有助于FastMM从内存地址中解析函数名称。

Windows服务中的内存泄漏（CodeGear C ++ XE5）使用Indy TIdTCPServer

1 个答案: