Re: Valgrind and glib

["Alan M. Evans" <ame1 extratech com>]

On Tue, 2006-01-03 at 05:31, Ricardo Biloti wrote:
> There is a simple gslist test program which yields a non clean report
> when valgrind is employed. The "problem" seems to be in glib. Below I
> quote the program and the valgrind output:

[...]

> ==6578== 20 bytes in 1 blocks are still reachable in loss record 1 of 2
> ==6578==    at 0x1B906F75: calloc (vg_replace_malloc.c:175)
> ==6578==    by 0x1B94C96E: g_malloc0 (in /usr/lib/libglib-2.0.so.0.600.4)
> ==6578==    by 0x1B94E27C: g_allocator_new (in /usr/lib/libglib-2.0.so.0.600.4)
> ==6578==    by 0x1B95C638: (within /usr/lib/libglib-2.0.so.0.600.4)
> ==6578==    by 0x1B95BC23: g_slist_append (in /usr/lib/libglib-2.0.so.0.600.4)
> ==6578==    by 0x804852E: art_alloc_raycode (sample.c:23)
> ==6578==    by 0x80485CA: main (sample.c:76)
> ==6578==
> ==6578==
> ==6578== 1106 bytes in 3 blocks are still reachable in loss record 2 of 2
> ==6578==    at 0x1B90659D: malloc (vg_replace_malloc.c:130)
> ==6578==    by 0x1B94C8E6: g_malloc (in /usr/lib/libglib-2.0.so.0.600.4)
> ==6578==    by 0x1B95C8C8: g_strdup (in /usr/lib/libglib-2.0.so.0.600.4)
> ==6578==    by 0x1B94E286: g_allocator_new (in /usr/lib/libglib-2.0.so.0.600.4)
> ==6578==    by 0x1B95C638: (within /usr/lib/libglib-2.0.so.0.600.4)
> ==6578==    by 0x1B95BC23: g_slist_append (in /usr/lib/libglib-2.0.so.0.600.4)
> ==6578==    by 0x804852E: art_alloc_raycode (sample.c:23)
> ==6578==    by 0x80485CA: main (sample.c:76)

[...]

> Could this be something "dangerous"?

No. GAllocators keep private globals meant to be freed automatically by
the OS at program exit. Suggest adding any reported leak that mentions
g_allocator_new to your valgrind suppressions.