Delphi 6 に同梱されている RTL/VCL には、いくつかのメモリ リークが含まれています。Delphi の以降のリリースでは、FastMM の使用により、これらのメモリ リークが RTL/VCL から削除されました。
必要なことは、これらの既知および予想されるメモリ リークを FastMM に登録することです。リークを登録すると、FastMM はそれらを報告しません。これらのリークは現実のものですが、さまざまな理由から無視するのが最善です。
- これらの既知の VCL リークによるメモリ リークはごくわずかであり、プロセスの存続期間中は増加しません。
- とにかくプロセスが終了するとすぐに、メモリはシステムに戻りました。
- リークは制御できないコードにあるため、できることはそれほど多くありません。それらを修正して、問題の VCL ユニットの独自のバージョンを使用することもできますが、それだけの価値はありますか?
これらのリークが問題になるのは、プロセスの存続期間中に同じプロセスから何千回もロードおよびアンロードされた DLL がある場合だけです。これはあまり現実的なシナリオではないと思います。
リークを登録しないと、FastMM リーク レポートは毎回表示されるため、ほとんど効果がありません。毎回表示される場合は、無視することを学びます。このリーク レポートは非常に価値がありますが、ある程度制御できるリークを示す場合にのみ価値があります。
私の Delphi 6 プロジェクトでは、.dpr ファイルに次のコードがあります。
// Register expected VCL memory leaks caused by Delphi unit HelpIntfs.
FastMM4.RegisterExpectedMemoryLeak(36, 2); // THelpManager x 1, THTMLHelpViewer x 1
FastMM4.RegisterExpectedMemoryLeak(20, 7); // TObjectList x 3, THelpSelector x 1, Unknown x 3
FastMM4.RegisterExpectedMemoryLeak(52); // TWinHelpViewer x 1
TFormまた、アプリ内のすべてのフォームが派生する子孫に次のものがあります。
var
ExpectedHelpStringMemoryLeakRegistered: Boolean;
procedure TMyForm.WMHelp(var Message: TWMHelp);
begin
if not (biHelp in BorderIcons) and not ExpectedHelpStringMemoryLeakRegistered then begin
// Register expected VCL memory leaks caused by Delphi unit HelpIntfs.
FastMM4.RegisterExpectedMemoryLeak(44); // TString x 1
ExpectedHelpStringMemoryLeakRegistered := True;
end;
inherited;
end;
RTL/VCL で使用するユニットとその使用方法によっては、異なるメモリ リークを登録する必要がある場合があります。