Valgrind reports memory 'possibly lost' when using glib data types

Question

I'm developing a library using a number of glib datastructures (GHashTable, GSList etc.). I've been checking my code frequently for memory leaks using valgrind. Most of the issues valgrind points out are quite easy to fix, however there's a few that I can't figure out.

All of these are reported as 'possibly lost'.

At the top of the valgrind stacktrace, I always find the same 4 libraries:

==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)

Further down in the call stack, there is always a call to a glib function, such as g_key_file_new(), g_slist_prepend(), g_strsplit(), g_key_file_load_from_file(), g_file_get_contents().

My questions are:

• Has anyone come across this and found a way around it?

• Or is this something I can disregard? Is it due to glib using memory pools, as suggested here?

I am using

• valgrind-3.5.0
• glib-2.12.3
• gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
• CentOS release 5.5 (Final)

Answer 1

GLib has a few features that confuse Valgrind.

One is memory pools (g_slice in newer glib, "mem chunks" in older). These are specialized allocators used for small objects such as list nodes. You can use this to disable the slice allocator: G_SLICE=always-malloc valgrind myprogram

A second issue is that sometimes GLib would avoid initializing new memory or keep dead pointers in freed slices/chunks. You can fix this with: G_DEBUG=gc-friendly valgrind myprogram

So together of course: G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind myprogram

A third issue is that GLib has global variables that are simply never freed but considered permanent program state. For example registered GType are never unloaded, and a few others. This is not fixable, but valgrind should show these global allocations as reachable, rather than as lost.