Re: memory leak with gtk+-2.8.20-r1

[Michael Torrie <torriem chem byu edu>]

On Sun, 2006-08-06 at 20:55 +0200, Vincent Torri wrote:
> > > ==29096==    still reachable: 41,380 bytes in 618 blocks.
> > That's completely normal. Surely they're static variables holding
> > pointers to freed memory.
>
> maybe this comes from glib memory allocator. I have such results with 
> gstreamer too

Glib can be compiled to use a leak-detector-friendly allocator rather
than the pool on that it currently uses.  It is my experience that
you'll get unreliable valgrind data without recompiling glib

> From http://developer.gnome.org/doc/API/2.0/glib/glib-building.html:

"--disable-gc-friendly and --enable-gc-friendly.  By default, and with
--disable-gc-friendly as well, Glib does not clear the memory for
certain objects before they are freed. For example, Glib may decide to
recycle GList nodes by putting them in a free list. However, memory
profiling and debugging tools like Valgrind work better if an
application does not keep dangling pointers to freed memory (even though
these pointers are no longer dereferenced), or invalid pointers inside
uninitialized memory."

Also this option seem to be appicable:
"--disable-mem-pools and --enable-mem-pools.  Many small chunks of
memory are often allocated via collective pools in GLib and are cached
after release to speed up reallocations. For sparse memory systems this
behaviour is often inferior, so memory pools can be disabled to avoid
excessive caching and force atomic maintenance of chunks through the
g_malloc() and g_free() functions."

> Vincent
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list