Re: possible g_hash_table mem leak?

["David Necas (Yeti)" <yeti physics muni cz>]

On Tue, Jan 04, 2005 at 04:59:19PM -0500, Tristan Van Berkom wrote:
> 
> Hmmm, maybe you found a leak;

If the memory is still reachable (like in this case), then
it's an eventual leak, not a leak.  In practice, reachable
not freed memory is usually the allocate-once-in-a-lifetime
case, i.e., memory that could be freed at program exit if
anyone bothered to.  Sometimes it's memory someone should
bother to free, but not in this case IMHO.

> Why dont you try running valgrind with `--num-callers=20', then
> we can see who was responsable for allocating those 1076 bytes :)

It's the chunk allocator for nodes.  If you destroy the hash
table and create again, the memory is reused.  Try
valgrinding this:

=================================
#define _GNU_SOURCE
#include <stdio.h>
#include <glib.h>
int
main(void)
{
    GHashTable *h;
    char *a, *b;
    gint i;

    for (i = 0; i < 10000; i++) {
        h = g_hash_table_new_full(g_str_hash, g_str_equal, g_free, g_free);
        asprintf(&a, "%d", i);
        asprintf(&b, "%d", i);
        g_hash_table_insert(h, a, b);
        g_hash_table_destroy(h);
    }

    return 0;
}
=================================

See the difference? (there's none)

Under normal circumstances hash nodes are created, and freed,
an created, and freed..., and the reuse is OK.

You can change the allocators if your circumstances are
abnormal, but I've never had any need to, so I can't tell
more.

Yeti


--
Dynamic IP address is not a crime.