Bug 205281 - glib's hash functions leak memory.
Summary: glib's hash functions leak memory.
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glib2
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-09-05 19:14 UTC by Peter Jones
Modified: 2007-11-30 22:11 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2006-09-05 19:19:10 UTC


Attachments (Terms of Use)

Description Peter Jones 2006-09-05 19:14:39 UTC
create and then destroy a ghash and you don't get all the memory back.  Here's a
test program:

#include <glib.h>
int main(void) {
    GHashTable *table = g_hash_table_new(g_str_hash, g_str_equal);
    g_hash_table_destroy(table);
    return 0;
}

Compile it:

localhost:~$ gcc $(pkg-config --libs --cflags glib-2.0) -Wall -Werror -o ghash
ghash.c
localhost:~$ 

And run it under valgrind:
localhost:~$ sudo valgrind --leak-check=full --show-reachable=yes
~/ghash==31032== Memcheck, a memory error detector.
==31032== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==31032== Using LibVEX rev 1606, a library for dynamic binary translation.
==31032== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==31032== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
==31032== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==31032== For more details, rerun with: -v
==31032== 
==31032== 
==31032== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 682 from 1)
==31032== malloc/free: in use at exit: 5,580 bytes in 8 blocks.
==31032== malloc/free: 9 allocs, 1 frees, 5,624 bytes allocated.
==31032== For counts of detected errors, rerun with: -v
==31032== searching for pointers to 8 not-freed blocks.
==31032== checked 75,996 bytes.
==31032== 
==31032== 2,016 bytes in 4 blocks are still reachable in loss record 1 of 2
==31032==    at 0x401F5C6: memalign (vg_replace_malloc.c:332)
==31032==    by 0x401F620: posix_memalign (vg_replace_malloc.c:386)
==31032==    by 0x4075B63: slab_allocator_alloc_chunk (gslice.c:1065)
==31032==    by 0x4076597: g_slice_alloc (gslice.c:614)
==31032==    by 0x4052B18: g_hash_table_new_full (ghash.c:139)
==31032==    by 0x4052B97: g_hash_table_new (ghash.c:110)
==31032==    by 0x8048468: main (in /home/pjones/ghash)
==31032== 
==31032== 
==31032== 3,564 bytes in 4 blocks are still reachable in loss record 2 of 2
==31032==    at 0x401F705: calloc (vg_replace_malloc.c:279)
==31032==    by 0x40666ED: g_malloc0 (gmem.c:150)
==31032==    by 0x4075E7E: g_slice_init_nomessage (gslice.c:317)
==31032==    by 0x407638B: g_slice_alloc (gslice.c:347)
==31032==    by 0x4052B18: g_hash_table_new_full (ghash.c:139)
==31032==    by 0x4052B97: g_hash_table_new (ghash.c:110)
==31032==    by 0x8048468: main (in /home/pjones/ghash)
==31032== 
==31032== LEAK SUMMARY:
==31032==    definitely lost: 0 bytes in 0 blocks.
==31032==      possibly lost: 0 bytes in 0 blocks.
==31032==    still reachable: 5,580 bytes in 8 blocks.
==31032==         suppressed: 0 bytes in 0 blocks.

Comment 1 Matthias Clasen 2006-09-05 19:19:10 UTC
valgrind is not smart enough to handle the slice allocator thats used for hash nodes


Note You need to log in before you can comment on or make changes to this bug.