Administrace komentářů

Můj dotaz se týká datové struktury GHashTable. Když jsem svůj program nalouskal do Valgrindu zhrozil jsem se . Mimo svých chyb při práci s pamětí (které jsou již opravené)jsem si všiml jedné, které nepochází (asi) z mého kódu. Vytvořil jsem mini ukázku na které se dá chyba ukázat. Mám GHashTable, která má char * klíče i hodnoty. Ty by při volání g_hash_table_destroy() měli být dealokovány pomocí g_free() spolu s mojí GHashTable *hash.

#include <glib.h>

int main(int argc, char **argv)
{
    GHashTable *hash = g_hash_table_new_full(g_str_hash, g_str_equal, g_free, g_free);
    gchar *key = "klic";
    gchar *val = "val";

    g_hash_table_insert(hash, g_strdup(key), g_strdup(val));

    g_hash_table_destroy(hash);
    return 0;
}

Program kompiluji takto:

 gcc -Wdisabled-optimization -O  -g -Wall -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lglib-2.0 test.c

Když jsem zagooglil, zjistil jsem, že memleak může být Valgrindem reportován kvůli slice alocatoru, který používá Glib a že je před použitím Valgrindu potřeba vyexportovat proměnné, který donutí program nepoužívat slice allocator a další glib finty na práci s pamětí. Pouštím tedy:

export G_SLICE=always-malloc && export G_DEBUG=gc-friendly

A následně pouštím Valgrind:

michal@neotronic-ntb:/tmp$ valgrind --leak-check=full --show-reachable=yes ./a.out
==19278== Memcheck, a memory error detector.
==19278== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==19278== Using LibVEX rev 1854, a library for dynamic binary translation.
==19278== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==19278== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==19278== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==19278== For more details, rerun with: -v
==19278==
==19278==
==19278== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==19278== malloc/free: in use at exit: 1,524 bytes in 3 blocks.
==19278== malloc/free: 8 allocs, 5 frees, 1,629 bytes allocated.
==19278== For counts of detected errors, rerun with: -v
==19278== searching for pointers to 3 not-freed blocks.
==19278== checked 74,224 bytes.
==19278==
==19278== 1,524 bytes in 3 blocks are still reachable in loss record 1 of 1
==19278==    at 0x4021E22: calloc (vg_replace_malloc.c:397)
==19278==    by 0x407F50B: g_malloc0 (gmem.c:151)
==19278==    by 0x40941CA: g_slice_init_nomessage (gslice.c:329)
==19278==    by 0x4095F34: g_slice_alloc (gslice.c:359)
==19278==    by 0x4069678: g_hash_table_new_full (ghash.c:347)
==19278==    by 0x8048640: main (test.c:5)
==19278==
==19278== LEAK SUMMARY:
==19278==    definitely lost: 0 bytes in 0 blocks.
==19278==      possibly lost: 0 bytes in 0 blocks.
==19278==    still reachable: 1,524 bytes in 3 blocks.
==19278==         suppressed: 0 bytes in 0 blocks.

A teď ten dotaz, dělám něco blbě já (nejpravděpodobnější možnost), valgrind má halucinace, nebo jsem narazil na memleak v glibu (o čemž pochybuji)?

Dík