Linux で実行されている大規模なマルチスレッド C++ アプリケーションがあります。アプリケーション メモリによって占有されているメモリが急速に増加していることがわかり、何らかのリークがあると考えられます。持っているすべてのツール (valgrind、DynLeak、Purify) を試しましたが、何も見つかりませんでした。このアプリケーションは Windows で実行できるため、Bounds Checker も試しました。助けにもなりませんでした。
役立つ新しいツールが必要です。Google Perfomrance Tools、Paul Nettle による MMGR、MemCheck Deluxe を見てきました。それらのどれも私に感銘を与えませんでした。
このタスクに適したツールはありますか?
C / C ++でのメモリリークの定義は非常に具体的です。割り当てられたメモリであり、ポインタが上書きされたか、その他の方法で失われました。Valgrindは通常、そのようなケースを箱から出して検出しますが、物事は必ずしもそれほど単純ではありません。
アプリケーションはまだそのメモリを使用している可能性があります。その場合、Javaプログラマーがリークと見なすものがあるかもしれません。たとえば、構造体にデータを入力し、エントリを削除することはめったにありません（またはまったく削除しません）。
メモリのメモリ使用量を誤って測定している可能性があります。Linuxでは、メモリ使用量の測定は見た目ほど簡単ではありません。メモリ使用量をどのように測定しましたか？
プログラムの終了時にのみレポートが発行されるという問題を回避するために、使用しているメモリ分析ツールのアプリケーションフック（Valgrindではクライアントリクエストと呼ばれます）の使用を検討する必要があります。これらのフックを使用すると、リークの場所を特定するのに役立つ場合があります。
Valgrindのmassifなどのヒーププロファイラーを使用して、割り当てられたメモリの量が多すぎるメモリ割り当て場所を探す必要があります。
アプリケーションでカスタムアロケータまたはガベージコレクタを使用していないことを確認してください。私の知る限り、ユーザーの干渉なしにカスタムアロケータで動作するメモリ分析ツールはありません。
メモリリークがアプリケーションの実行時に許容できる量内で検出できるほど大きい場合は、バージョン管理システムを介して古いリビジョンのバイナリ検索を試行し、問題の原因となったコミットを特定できます。少なくともMercurial とGitは、このタスクの組み込みサポートを提供します。
「役に立たなかった」とは、メモリリークが報告されなかったことを意味する場合、メモリリークがなく、ポインタによって参照され、削除できるメモリをどんどん使用している可能性があります。
問題をデバッグするのに役立つように、おそらくログに、メモリ サイズ、オブジェクトの数 (それらのタイプ)、および役立つ他のいくつかの統計情報も書き込む必要があります。少なくとも、あなたが言及したツールに慣れるまでは.