问题
This question is not a duplicate of many others, bekause I do use G_DEBUG=gc-friendly
and G_SLICE=always-malloc
Here is the source code:
#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;
}
And here is Valgrind's output on this code:
# 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)
Is it a memory-leak?
回答1:
To answer your question: No, this is not a memory leak in the traditional sense. Your code is fine.
Even if you use G_DEBUG=gc-friendly
and G_SLICE=always-malloc
, GLib always leaves "still reachable" memory on exit. Don't use the --show-reachable=yes
option, otherwise you'll always have a polluted Valgrind output when using GLib. However, be careful if you allocate memory to which you keep pointers in static or global variables ("still reachable" memory). In this case you might end up ignoring your own "real" leaks.
回答2:
I have always had trouble with a lot of false and unreachable items when using Valgrind to check GLib 2 programs. In your case, the leaks seem to be from the creation of the hash table. I would create a second hash table and see if you get additional blocks (otherwise, it could be some internal initialization in GLib).
Some notes on using Valgrind with GLIB and GTK are at wiki.gnome.org.
回答3:
Try passing --suppressions=/usr/share/glib-2.0/valgrind/glib.supp
to valgrind
. It suppresses the false positives from GLib.
来源:https://stackoverflow.com/questions/12389092/does-glib2-actually-leak-memory-with-always-malloc