【发布时间】:2012-05-19 21:42:17
【问题描述】:
很长一段时间以来,我都注意到我的服务器应用程序的 Win64 版本会泄漏内存。虽然 Win32 版本在内存占用相对稳定的情况下运行良好,但 64 位版本使用的内存定期增加 - 可能 20Mb/天,没有任何明显的原因(不用说,FastMM4 没有报告任何内存泄漏) . 32 位和 64 位版本的源代码相同。该应用程序是围绕 Indy TIdTCPServer 组件构建的,它是一个高度多线程的服务器,连接到数据库,处理由 Delphi XE2 生成的其他客户端发送的命令。
我花了很多时间检查自己的代码并试图理解为什么 64 位版本会泄漏这么多内存。我最终使用了旨在跟踪内存泄漏的 MS 工具,如 DebugDiag 和 XPerf,似乎 Delphi 64 位 RTL 中存在一个基本缺陷,每次线程与 DLL 分离时都会导致一些字节泄漏。对于必须 24/7 不间断运行且无需重新启动的高度多线程应用程序,此问题尤其严重。
我用一个非常基本的项目重现了这个问题,该项目由一个主机应用程序和一个库组成,两者都是用 XE2 构建的。 DLL 与主机应用程序静态链接。宿主应用程序创建的线程只调用虚拟导出过程并退出:
这里是库的源代码:
library FooBarDLL;
uses
Windows,
System.SysUtils,
System.Classes;
{$R *.res}
function FooBarProc(): Boolean; stdcall;
begin
Result := True; //Do nothing.
end;
exports
FooBarProc;
宿主应用程序使用一个计时器来创建一个只调用导出过程的线程:
TFooThread = class (TThread)
protected
procedure Execute; override;
public
constructor Create;
end;
...
function FooBarProc(): Boolean; stdcall; external 'FooBarDll.dll';
implementation
{$R *.dfm}
procedure THostAppForm.TimerTimer(Sender: TObject);
begin
with TFooThread.Create() do
Start;
end;
{ TFooThread }
constructor TFooThread.Create;
begin
inherited Create(True);
FreeOnTerminate := True;
end;
procedure TFooThread.Execute;
begin
/// Call the exported procedure.
FooBarProc();
end;
这里是一些使用 VMMap 显示泄漏的屏幕截图(查看名为“Heap”的红线)。以下屏幕截图是在 30 分钟内拍摄的。
32位二进制显示增加了16字节,完全可以接受:
64位二进制显示增加了12476字节(从820K到13296K),问题比较多:
堆内存的不断增加也得到了XPerf的证实:
使用 DebugDiag 我能够看到分配泄漏内存的代码路径:
LeakTrack+13529
<my dll>!Sysinit::AllocTlsBuffer+13
<my dll>!Sysinit::InitThreadTLS+2b
<my dll>!Sysinit::::GetTls+22
<my dll>!System::AllocateRaiseFrame+e
<my dll>!System::DelphiExceptionHandler+342
ntdll!RtlpExecuteHandlerForException+d
ntdll!RtlDispatchException+45a
ntdll!KiUserExceptionDispatch+2e
KERNELBASE!RaiseException+39
<my dll>!System::::RaiseAtExcept+106
<my dll>!System::::RaiseExcept+1c
<my dll>!System::ExitDll+3e
<my dll>!System::::Halt0+54
<my dll>!System::::StartLib+123
<my dll>!Sysinit::::InitLib+92
<my dll>!Smart::initialization+38
ntdll!LdrShutdownThread+155
ntdll!RtlExitUserThread+38
<my application>!System::EndThread+20
<my application>!System::Classes::ThreadProc+9a
<my application>!SystemThreadWrapper+36
kernel32!BaseThreadInitThunk+d
ntdll!RtlUserThreadStart+1d
Remy Lebeau helped me on the Embarcadero forums 了解发生了什么:
第二次泄漏看起来更像是一个明确的错误。线程期间 关机,StartLib() 被调用,它调用 ExitThreadTLS() 来 释放调用线程的 TLS 内存块,然后调用 Halt0() 调用 ExitDll() 来引发一个被 DelphiExceptionHandler() 调用 AllocateRaiseFrame(),它 间接调用 GetTls() 并因此调用 InitThreadTLS() 名为 ExceptionObjectCount 的 threadvar 变量。重新分配 仍在进程中的调用线程的 TLS 内存块 被关闭。所以要么 StartLib() 不应该调用 在 DLL_THREAD_DETACH 期间 Halt0(),否则 DelphiExceptionHandler 应该 当它检测到一个不调用 AllocateRaiseFrame() _TExitDllException 正在引发。
对我来说似乎很清楚,Win64 处理线程关闭的方式存在重大缺陷。这种行为禁止开发任何必须在 Win64 下 27/7 运行的多线程服务器应用程序。
所以:
- 您如何看待我的结论?
- 你们有解决此问题的方法吗?
【问题讨论】:
-
“你们有解决这个问题的办法吗?”我会使用 32 位应用程序,直到下一个带有 64 位编译器的
stable 版本的 delphi 出现。 .. -
如果我是你,我会将其缩减为最小尺寸的样本,显示泄漏,然后简单地将其提交给 QC。
-
@whosrdaddy 也有同样的感觉,我希望我们错了):
-
很有趣,似乎在 2009 年已经报告了相同类型的错误(我想它是在 Win32 RTL 中):embarcadero.newsgroups.archived.at/public.delphi.rtl/200903/…qc.embarcadero.com/wc/qcmain.aspx?d=72439 不过它似乎已经修复现在因为我的测试项目的 Win32 版本不会泄漏内存。
-
@Cœur 这是一个自动脚本,它只执行我告诉它去做的事情。我猜剩余的 imageshack.us 链接没有被检测为图像,我不确定 free.fr 的链接。它本可以在去年 8 月运行。
标签: delphi memory-leaks delphi-xe2 win64