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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
