Bug 205281 - glib's hash functions leak memory.
glib's hash functions leak memory.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glib2 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-05 15:14 EDT by Peter Jones
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-05 15:19:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Jones 2006-09-05 15:14:39 EDT
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 15:19:10 EDT
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.