Windows Service (CodeGear c++ XE5)内存泄漏

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中是众所周知的泄漏，只发生在应用程序关闭时，因为它们是故意不释放的全局对象。我很惊讶在泄漏报告中看到它们，因为Indy将它们注册为已知泄漏。

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

我发现奇怪的是，泄漏似乎是在单元最终化期间分配的，而不是在应用程序的正常运行期间，但为什么有这么多的Finalize调用在一起，我不知道。除非应用程序的堆栈跟踪信息出错。FastMM无法报告更有意义的信息，因为这些单元可能没有在启用调试信息的情况下编译。你是否至少有一个由编译器为你的应用程序生成的。map文件?这有助于FastMM从内存地址解析函数名。