私はこの比較的大きな数値アプリケーション コードを持っています。これは数日間実行され、最終的にいくつかの数値を吐き出す可能性があります。全体が C++ で書かれており、多数のサードパーティ ライブラリを利用し、GCC 4.6 を使用してコンパイルされています。コード全体で共有ポインターを使用します。
残念なことに、時間が経つにつれて、コードのメモリ消費量が増加し、すべての (共有) メモリが使い果たされてクラッシュします。アルゴリズム的に、コードは時間の経過とともにメモリを構築するべきではないため、どこかにバグがあるでしょう。
valgrind のリーク チェッカーを使用して小さな例を実行しましたが、すべて問題ないことが報告されました。私の考えでは、共有ポインターが意図せずにどこかに作成され、プロセス中に不要なデータが解放されるのを防いでいる可能性があります (ただし、これは単なる推測です)。
結局のところ、そのようなことをデバッグする方法のアイデアが不足しています。何か案は？
すでにvalgrindツールスイートを利用できるので、 massifツールを実行することをお勧めします。
Massifはメモリ割り当ての起点を追跡し、レポートは各割り当てサイト/関数が作成したバイト数を示します。これは、そのメモリの爆発がどこから来ているのかを理解するのに役立ちます。
GNU libstdc++ はデフォルトで STL 関連のメモリ割り当てをキャッシュしますが、これは明らかにマイクロベンチマークの速度の理由によるものです。ただし、実際の影響は、tcmalloc や jemalloc などのアロケータを使用する場合、速度とメモリ フットプリントの両方でかなりマイナスになる傾向があります。tcmalloc は、環境で GLIBCPP_FORCE_NEW=1 および GLIBCXX_FORCE_NEW=1 を設定することによってこの動作を無効にします (それぞれlibstdc++バージョン 3.3 および 3.4 の場合)。したがって、一般的には、アプリケーションを起動するときに適切な環境変数を設定することをお勧めします。
リークがない場合でも、メモリの断片化に直面する可能性があります。
Linuxを使用している場合は、jemallocアロケータを試してみることをお勧めします。Linux上でうまく動作します。これは多くのアーキテクチャーで実行され、zLinux（IBM zSeriesメインフレーム）でも正常に使用しました。使い方はとても簡単です。アプリケーションやライブラリを再構築する必要はありません。jemallocをビルドして、LD_PRELOAD次のようなセットでアプリケーションを起動するだけです。LD_PRELOAD=/usr/lib/libjemalloc.so <app>