ソケットからデータを受け取り、品質管理やその他のさまざまな条件付けを行ってから、名前付きパイプに書き出すプログラムがあります。その上でvalgrindを実行し、元々存在していたすべてのメモリリークを修正しました。次に、このプログラムの32個のインスタンスを実行し、それぞれに固有のデータが供給され、それぞれが独自のパイプに出力されるシステム上に「デモ」環境を作成しました。私たちはそれをテストしました、そしてすべてがうまく見えました。次に、データが送信される速度をばかげた速度に上げてストレステストを試みましたが、最初は問題がないように見えました...しかし、リソースがなくなるまで、プログラムはますます多くのメモリを消費し続けました。
私はvalgrindに目を向け、leak-check = fullを使用してvalgrind内で実行されている各プログラムを除いて、まったく同じセットアップを実行しました。いくつかの奇妙なことが起こりました。まず、メモリがリークしましたが、各プログラムが私のメモリの.9％を消費したところまでしかありませんでした（以前は、最大のメモリホッグが私のメモリの6％を完全に消費していました）。valgrindを実行すると、プログラムのCPUコストが急上昇し、現在は100％CPUで、負荷平均が非常に大きいため、使用可能なCPUが不足しているため、プログラムの実行速度が遅くなり、リークが発生するまでに時間がかかりすぎた可能性があります。 。これらのプログラムを停止しようとすると、valgrindは直接のメモリリークを示さず、潜在的なメモリリークを示しましたが、チェックしたところ、実際のメモリリークを表すものはないと思います。さらに、プログラムが100 MB以上を消費している間、メモリリークの可能性は数キロバイトとしてしか示されませんでした。valgrindによって報告された到達可能な（リークされていない）メモリもKBの範囲内であったため、valgrindは、私のプログラムがTopが使用していると言っているメモリの一部を消費していると考えているようです。
他のいくつかのテストを実行しましたが、奇妙な結果が得られました。1つのプログラムは、元のメモリリークが検出された速度の3倍で実行されていても、.9％を超えるメモリを消費することはなく、2つのプログラムはそれぞれ最大1.9％と1.3％のメモリをリークしますが、それ以上はありません。リークされたメモリの量とリークの速度は、プログラムのインスタンスが一度にいくつ実行されているかに何らかの形で依存します。これは意味がありません。各インスタンスは他のインスタンスから100％独立している必要があります。
また、valgrindで1つのインスタンスのみを実行して32のインスタンスを実行すると、valgrindedインスタンス（つまり、そうだと言えばそうです！）がメモリリークを起こしますが、valgrindの外部で実行されているインスタンスよりも低速です。valgrindインスタンスは、直接リークがないことを示し、Topが示すよりもはるかに少ないメモリ消費量を報告します。
何がこの結果を引き起こしているのか、そしてなぜvalgrindがメモリリークの認識を拒否するのかについて、私はかなり困惑しています。外部のライブラリかもしれないと思いましたが、実際には外部のライブラリは使用していません。基本的なC++関数/オブジェクトだけです。また、出力パイプに書き込まれたデータが高速でバッファが無期限に大きくなる可能性があると考えましたが、1）そのようなバッファが大きくなる上限があり、2）データをドロップするとメモリがリークした場合入力レートをゼロにすると、メモリは消費されたままになり、適度な量にゆっくりと戻ります。
誰かが私がここからどこを見るべきかについてのヒントを私に与えることができますか？なぜ記憶がこのように振る舞うのか、私は完全に困惑しています。
ありがとう。