2

私のアプリケーションには、検出されない無限に成長するメモリ リークがあるという問題があります。オブジェクトを作成し、メソッドを実行してから、オブジェクトを削除します。これを行うたびに、TaskManager のメモリ使用量が約 50 ～ 100MB 増加します。これは、いくつかの実行後に私の記憶全体を使い果たします。マルチスレッドでこれを行いますが、静的変数がないため、スレッド内の異なるオブジェクト間に衝突はありません。パラメータで渡された以外のメモリを変更しない、他のオブジェクトの静的メソッドのみを使用するため、スレッドセーフです。理由を調べようとしたこと：

  • crtdbg.h (CRT-Memeory-Leak-Detection) を使用しますが、アプリケーションの開始以降に存在するリークのみがあります。それらはシャットダウン時に削除され、それほど大きくはありません。
  • 継承元のすべてのオブジェクトで仮想デストラクタを探していましたが、すべて問題ありません

アプリケーションがリークしている場所を見つけるには、他に何ができますか? HEAP でリークを見つけることができず、STACK でリークを引き起こす可能性のあるデストラクタの問題以外の理由もわかりません (これは、オブジェクトがローカルの std::string オブジェクトを破棄しないことを意味します)。ヒープにスペースが割り当てられています)。「STACK-Leaks」の他の理由があるかどうかはわかりませんが、メモリが最も大きくなるメソッドの部分では、HEAP 割り当てがないことはわかっています。

4

2 に答える 2

1

CRTDBG ライブラリをどのように使用したかはわかりませんが、多くの利点があります。

http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx

_CrtMemCheckpoint を分割統治法で使用できます。コード内の 2 点間のメモリ使用量の差を測定できます。マルチスレッドでは、これは困難な場合があります。

もう 1 つは、_CRTDBG_MAP_ALLOC が有効になっている _CrtDumpMemoryLeaks (アプリの終了時に実行されると思われます) です。これは、メモリ割り当ての正確な場所を示すはずです。

もう 1 つのヒントは、CRTDBG が過剰に構成されている可能性があることです。多くの小さな割り当てにより、巨大な内部メモリ構造が作成される可能性があります。

コードの一部をオフにしてみて、問題が解決しないかどうかを確認してください。

アプリを毎日ビルドする場合は、以前のバージョンを実行して問題が発生した場所を特定し、ソース コード リポジトリの変更を比較してみてください。

...

于 2012-07-17T15:35:14.233 に答える
1

おそらく、より優れた、より堅牢な漏れ検出器を使用したいと思うでしょう。また、プログラムの実行中にさまざまな時点でヒープ レポートを出力できるリーク検出器を使用する必要がある場合もあります。最後に、問題は単なるリークではなく、ヒープの断片化が原因である可能性があることを考慮する必要があります。

Google から無料で提供されているVisual Leak Detectorを試すことができます。

この質問には、基本的なものから非常に高度な/高価なものまで、他のメモリ チェック製品のリストが含まれています。CRTDBG は最小公分母ソリューションです。無料ではありませんが、私は BoundsChecker でうまくいきました。

于 2012-07-17T14:47:26.680 に答える