does glib2 actually leak memory with ALWAYS-MALLOC

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:

I have always had trouble with a lot of false and unreachable items when using Valgrind to check GLIB2 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 here wiki.gnome.org

回答2:

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.