Re: all about gobject references

[David Nečas <yeti physics muni cz>]

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