7

FAstMMは、IdStack.pasのTIdCriticalSectionからのメモリリークを報告します。これは意図的なリークであり、コードに記載されていることを理解しています。

私が理解していないのは、IdStackが私のプロジェクトに含まれている理由です。どのユニットがそれを引き込んでいるかをどのように知ることができますか？

delphi 2007に付属しているバージョンのfastmmを使用して、このリークをレポートから除外する方法はありますか？

更新：ビルドに含まれるすべてのpasファイルを見つける方法はありますか？

4

4 に答える 4

8

DelphiFastMMメモリマネージャはメソッドを提供します

function RegisterExpectedMemoryLeak(P: Pointer): boolean;

したがって、ユニットを見つけて、それを取り外すことができないことが判明した場合は、この方法を使用して、メモリリークの警告を抑制することができます。

于 2009-08-13T12:28:28.817 に答える
4

すべてのIndyユニットには「Id」プレフィックスが付いているため、uses句にそれらのいずれかがあるかどうかを確認してください。

別の方法は、TIdStack.create（）にブレークポイントを設定することです。最終的に、有罪者はコールスタックに表示されます。

于 2009-08-13T09:16:04.887 に答える
4

散らばっていますが、ネット上にはこれについてたくさんあります。Indy 9（D7付き）以降を使用しているかどうかによっても異なります。それも私を悩ませました。Indy 9の場合、IdComponent.pasで次のことを行いました。

initialization
  GStackCriticalSection := TCriticalSection.Create;

  // BJF Starts
  //RegisterExpectedMemoryLeak(GStackCriticalSection);
  // BJF Ends

finalization
  // Dont Free. If shutdown is from another Init section, it can cause GPF when stack
  // tries to access it. App will kill it off anyways, so just let it leak

  // BJF has removed comments
  FreeAndNil(GStackCriticalSection);
end.

ただし、ライブラリパスにIndyソースへのパスを配置する必要があることに注意してください。Indy10はこの点で修正されていると思います。ブライアン

于 2009-08-13T16:26:00.627 に答える
2

.dprの使用を確認します。cnPack（cnPack.org）を使用し、[クリーナーを使用]を選択して、参照されていないユニットを削除します。

于 2009-08-13T11:14:38.280 に答える