More explanation of g_blow_caches / g_debug_shutdown

[Michael Meeks <michael ximian com>]

Hi Tim,

        Thanks for responding; you said some interesting and most
encouraging things.

On Sat, 10 Nov 2001, Tim Janik wrote:
> this does indeed add quite some overhead for the common case. so much
> that i don't consider it implementing for many of my code portions. to
> give a few examples:

...  (GQuark, type system )...

        I was thinking of doing this purely for GObject instances - which
already have a ref count, and already have a tracking system for them; and
are typicaly somewhat more heavyweight and thus I think there are
(probably)  relatively few places where we deliberately loose references
to them.

        Of course - with the same API you could try and be super clever
and track each malloc'd block; but I'd settle for just objects.

> huh, there're exactly *0* things you can do after you've torn down
> your program like that.
        
        Well - not neccessarily; all I'm interested in is providing an   
optional (debug only) way of examining what resources are lying around to   
determine whether you have leaked anything. There is no particular need to
do any violence to the resources themselves really - apart from flushing
caches ( as you say ) - and again :-) I'm not particularly interested in
the g_malloc / g_realloc / g_free block counting possibilities.
  
> as an aside, i betcha, that if we introduced real shutdown functions,
> we'll get a lot of user requests ala:
  
        Well - calling it 'debug_shutdown' and not advertising it's
presence over-widely might help stop people moaning about it. It could
also spew some unfriendly message ( like gtk_init ) unless you have an
environment variable set; but ... this is speculation.
 
> you've just seen the stale object hashtable dump at the end of a
> program right?
 
        Yes - it's very nice, but try running a Gtk+ program with it
turned on, as soon as I display a label or two I get a _very_ substantial
number of false positives from the dump;
 
        Also - I'd really like a method that ( in combo. with
G_ENABLE_DEBUG ) allowed me to return a status ( not an atexit method )
that I could spew back in a regression test to ensure that I had not
leaked anything.
 
> it'd probably be a good idea to add those for other refcounted things
> as well, what comes to mind are:

        Sure - there are lots of interesting possibilities - all flowing
from the desire to be able to verify that nothing leaks.

> i hope i could bring across a few of the points on why i'm not very
> comfortable with some of the points you raised.

        My explanation was not over clear - I'd like to restrict this to
just GObjects ( and anything else easy / not particularly invasive ).

> i do think you have a basic point though, and we definitely need to do
> some leak checking, and for that, automation is badly required. the   
> things i'm thinking about are not as radical though, i.e. i'd like to
> see:

        Horay ! you're my hero - so much ! :-) thanks.

> - a function glib/gdk/gtk _blow_caches() that blows internal
>   object/memory caches where this can be implemented without additional
>   complexity or track keeping. this would not cause the program to enter
>   an invalid (shutdown) state though, it'd even be usefull for
>   out-of-mem situations on embedded devices.
        
        Sure - that sounds wonderful too - just something I can call to
make the debug output useful; we really only need very few public methods,
and a few internal cache blowing things.

        I'm also _very_ happy to do the work; if _blow_caches sounds ok to
you - I'm keen to hack it up; just give the word ...

> - i would have liked to be able to flag static mallocs or static
> objects

        Again - I'm aiming high at a high 3rd :-) a simple GObject ref
tracking method would make me happy and shut me up for a long time. But I
really would like to be able to return a status for automated tests - thus
an atexit method is not my preferred solution.
  
        So ... what do you suggest ?

        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot