4

この質問は、他の多くの質問と重複していません。私が使用G_DEBUG=gc-friendlyしているためG_SLICE=always-malloc です。ソースコードは次のとおりです。

#include <glib.h>

int main (int argc, char *argv[])
{
    GHashTable *ht;
    ht=g_hash_table_new(g_str_hash,g_str_equal);
    g_hash_table_insert(ht,"foo","bar");
    g_hash_table_destroy(ht);
    return 0;
}

このコードに対する Valgrind の出力は次のとおりです。

# G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind --leak-check=full --show-reachable=yes ./test_vg
==1880== Memcheck, a memory error detector
==1880== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1880== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==1880== Command: ./test_vg
==1880==
==1880==
==1880== HEAP SUMMARY:
==1880==     in use at exit: 1,260 bytes in 3 blocks
==1880==   total heap usage: 5 allocs, 2 frees, 1,524 bytes allocated
==1880==
==1880== 252 bytes in 1 blocks are still reachable in loss record 1 of 3
==1880==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==1880==    by 0x35C8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x35C8255742: ??? (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x35C825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x35C822B1D2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x400671: main (in /home/data/test_vg)
==1880==
==1880== 504 bytes in 1 blocks are still reachable in loss record 2 of 3
==1880==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==1880==    by 0x35C8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x35C8255722: ??? (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x35C825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x35C822B1D2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x400671: main (in /home/data/test_vg)
==1880==
==1880== 504 bytes in 1 blocks are still reachable in loss record 3 of 3
==1880==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==1880==    by 0x35C8241707: g_malloc0 (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x35C825578B: ??? (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x35C825669D: g_slice_alloc (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x35C822B1D2: g_hash_table_new_full (in /lib64/libglib-2.0.so.0.2200.5)
==1880==    by 0x400671: main (in /home/data/test_vg)
==1880==
==1880== LEAK SUMMARY:
==1880==    definitely lost: 0 bytes in 0 blocks
==1880==    indirectly lost: 0 bytes in 0 blocks
==1880==      possibly lost: 0 bytes in 0 blocks
==1880==    still reachable: 1,260 bytes in 3 blocks
==1880==         suppressed: 0 bytes in 0 blocks
==1880==
==1880== For counts of detected and suppressed errors, rerun with: -v
==1880== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

それはメモリリークですか？

4

3 に答える 3

2

あなたの質問に答えるには: いいえ、これは従来の意味でのメモリ リークではありません。あなたのコードは問題ありません。

G_DEBUG=gc-friendlyandを使用してもG_SLICE=always-malloc、GLib は終了時に常に「まだ到達可能な」メモリを残します。このオプションを使用しない--show-reachable=yesでください。そうしないと、GLib を使用するときに常に汚染された Valgrind 出力が得られます。ただし、静的変数またはグローバル変数にポインタを保持するメモリ (「まだ到達可能な」メモリ) を割り当てる場合は注意してください。この場合、自分自身の「実際の」リークを無視してしまう可能性があります。

于 2014-08-16T18:00:43.000 に答える
1

Valgrind を使用して GLib 2 プログラムをチェックするとき、私は常に多くの誤ったアイテムや到達不能アイテムに悩まされてきました。あなたの場合、リークはハッシュテーブルの作成によるものと思われます。2 番目のハッシュ テーブルを作成し、追加のブロックを取得するかどうかを確認します (そうでない場合は、GLib の内部初期化である可能性があります)。

GLIB および GTK で Valgrind を使用する際の注意事項はwiki.gnome.org にあります。

于 2013-11-08T18:22:42.013 に答える