On Sat, Aug 22, 2009 at 09:01:43PM +0200, fidel wrote:
> A little off-topic, resp. about a similar issue, but I haven't found any
> reason for it:
> I read about using g_mem_set_vtable( glib_mem_profiler_table ) and using
> g_atexit( g_mem_profile ). Even in this short example, I still get
> memory leaks reported:
>
> #include <stdlib.h>
> #include <gtk/gtk.h>
> #include <glib.h>
>
> int main( int argc, char** argv )
> {
> g_mem_set_vtable( glib_mem_profiler_table );
> g_atexit( g_mem_profile );
>
> gtk_init( &argc, &argv );
>
> return EXIT_SUCCESS;
> }
>
> $ src/test
> ...
> GLib Memory statistics (failing operations):
> --- none ---
> Total bytes: allocated=967935, zero-initialized=120832 (12.48%),
> freed=710216 (73.37%), remaining=257719
>
> So even in this simple example there seem to occur memory leaks...
Where you see the evidence for leaks? I don't claim there are none but
memory not freed when the program exits is not a leak if it belongs to
something that is supposed to exist through the entire program lifetime.
> What just confuses me is the fact, that this should be a method for
> chasing memory leeks, but in such a case, this is not usable.
This could be a method for chasing memory leaks only if you could find
you what the allocated memory blocks and why. Which AFAIK you can't.
I suggest to make GLib use system memory allocation routines with
G_SLICE=always-malloc and use valgrind. *And* analyse the results as
there are quite a few things in GLib and Gtk+ that look like a leak but
are not. G_DEBUG=gc-friendly also helps slightly.
Yeti
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
