24

いくつかの glib データ構造 (GHashTable、GSList など) を使用してライブラリを開発しています。valgrind を使用して、コードのメモリ リークを頻繁にチェックしています。valgrind が指摘する問題のほとんどは簡単に修正できますが、私には理解できない問題がいくつかあります。

これらはすべて「失われた可能性がある」と報告されています。

valgrind スタックトレースの上部には、常に同じ 4 つのライブラリがあります。

==29997== 1,512 bytes in 3 blocks are possibly lost in loss record 24 of 25
==29997==    at 0x4004B11: memalign (vg_replace_malloc.c:532)
==29997==    by 0x4004B6B: posix_memalign (vg_replace_malloc.c:660)
==29997==    by 0x5E9AC4: ??? (in /lib/libglib-2.0.so.0.1200.3)
==29997==    by 0x5EA4FE: g_slice_alloc (in /lib/libglib-2.0.so.0.1200.3)

呼び出しスタックのさらに下には、g_key_file_new()、g_slist_prepend()、g_strsplit()、g_key_file_load_from_file()、g_file_get_contents() などの glib 関数への呼び出しが常にあります。

私の質問は次のとおりです。

  • 誰かがこれに遭遇し、それを回避する方法を見つけましたか?

  • それとも、これは私が無視できるものですか？ここで提案されているように、メモリプールを使用する glib が原因ですか?

私は使っている

  • valgrind-3.5.0
  • glib-2.12.3
  • gcc (GCC) 4.1.2 20080704 (レッドハット 4.1.2-48)
  • CentOS リリース 5.5 (最終版)
4

2 に答える 2

37

GLibには、Valgrindを混乱させるいくつかの機能があります。

1つはメモリプールです（新しいglibではg_slice、古いglibでは「memchunks」）。これらは、リストノードなどの小さなオブジェクトに使用される特殊なアロケータです。これを使用して、スライスアロケータを無効にすることができます。 G_SLICE=always-malloc valgrind myprogram

2番目の問題は、GLibが新しいメモリの初期化を回避したり、解放されたスライス/チャンクにデッドポインタを保持したりする場合があることです。これは次の方法で修正できます。 G_DEBUG=gc-friendly valgrind myprogram

もちろん一緒に： G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind myprogram

3番目の問題は、GLibには、解放されることはないが永続的なプログラム状態と見なされるグローバル変数があることです。たとえば、登録されたGTypeはアンロードされませんが、他にもいくつかあります。これは修正できませんが、valgrindは、これらのグローバル割り当てを、失われたものではなく、到達可能なものとして表示する必要があります。

于 2010-11-23T14:28:53.670 に答える
0

glib-2.12 はかなり古いです。

glib-2.24 を入手し、コンパイルしてインストールし (--prefix=/usr/local/glib-2.24たとえば)、それを使用してアプリケーションをコンパイルします。

まだこれがある場合は、glib のマニュアルをもう一度読んでみてください :)

于 2010-11-23T09:54:22.300 に答える