この記事では、なぜ単純に 提供されるコード スニペットは、 リーク チェックと原点追跡を有効にして Valgrind を介してこのプログラムを実行すると、次の出力が表示されます: これは、72,704 バイトがまだ残っていることを示します。プログラム内で明示的にメモリを割り当てていないにもかかわらず、到達可能です。 Valgrind の警告は懸念されるかもしれませんが、これは C プログラムでは一般的な動作であることを理解することが重要です。 C 標準ライブラリの多くの実装では、破棄されたオブジェクトのメモリをプールし、後で再利用する独自のメモリ プール アロケータが採用されています。この最適化されたメモリ管理技術により、メモリのオーバーヘッドが削減され、パフォーマンスが向上します。 ただし、Valgrind は、プログラム終了時に割り当てられたすべてのメモリがオペレーティング システムに返されるという想定に基づいて動作するため、これらのプールに保持されているメモリを次のように報告します。まだ到達可能です。これは必ずしもプログラムまたは Valgrind のバグではなく、むしろ期待の違いです。 Valgrind でまだ到達可能な警告を排除したい場合は、次のことができます。コンパイラ設定を変更して、STL (標準テンプレート ライブラリ) メモリ プールを無効にします。以下にいくつかの方法を示します。 GCC バージョン 2.91 から 3.1 では、-D__USE_MALLOC を使用してプログラムをコンパイルし、STL に malloc の使用を強制し、メモリを即座に解放することができます。ただし、このオプションは GCC 3.3 以降では削除されました。 GCC バージョン 3.2.2 以降では、プログラムを実行する前に環境変数 GLIBCPP_FORCE_NEW を設定できます。 GCC 3.4 以降の場合、環境変数名は GLIBCXX_FORCE_NEW です。 新しいコンパイラでは、-fno-optimize-sibling-calls フラグを使用して兄弟呼び出しを無効にすることができます。 STL メモリ プールを含む最適化 以上がC に `` を含めると、Valgrind の「まだ到達可能です」という警告が表示されるのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。プログラムと Valgrind の出力:
#include <iostream>
int main() {
return 0;
}
==27671== Memcheck, a memory error detector
... (output truncated)
...
==27671== 72,704 bytes in 1 blocks are still reachable in loss record 1 of 1
==27671== at 0x4C2AB9D: malloc (vg_replace_malloc.c:296)
==27671== by 0x4EC060F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
... (output truncated)
Valgrind の動作:
C ライブラリの最適化を無効にする:
__USE_MALLOC の使用:
環境変数の使用:
コンパイラ フラグの使用:
結論:
を含むヘッダーだけではメモリ リークは発生しませんが、C ライブラリのメモリ プール管理により、Valgrind でまだ到達可能な警告がトリガーされる可能性があります。この動作は予期されたものであり、バグではありません。 STL の最適化を無効にすると、これらの警告が表示されなくなりますが、パフォーマンスが低下する可能性があります。