Re: More explanation of g_blow_caches / g_debug_shutdown

[Michael Meeks <michael trna ximian com>]

Hi Owen,

        Ok - so there is no way we can do this in time for the freeze -   
which is extremely bad news for testing; but so be it. I am very hopeful 
that I can convince you for gtk+ 2.2.

On 19 Nov 2001, Owen Taylor wrote:
>  * debug_shutdown() is far from a perfect memory leak detection tool;
>    it basically has the same problem as doing leak detection with  
>    conservative GC; if you are keeping a block around in a cache
>    somewhere, you will not treat it as a leak, even if you have
>    allocation growing without bound.

        While you are right - clearly bloating caches cannot be detected
easily; neccessarily a _debug_shutdown method _ensures_ that there are not
'hidden' or 'unknown' caches; since they have to be explicitely blown.  

        Thus - you only ever get 100% accurate reports from a
_debug_shutdown, modulo bugs in the _blow_caches impl - ( which need
fixing in the same way as any referencing bug ), ie. you never get a false
negative.

        This coupled with the fact that the code can run with negligable
performance impact, in-place - and give you a 'leaked / didn't leak'
status at the end; with no code impact - I believe makes it a very
powerful tool.

        Furthermore - I am prepared to bet money that if implemented it
would trivialy find several (as yet undetected) leaks in the Gtk+/Gdk
code.

>    Then, in my opinion, you will be in a good position to find
>    almost any memory leak.

        Sure - you'll find any staggeringly large leaks because you'll
miss the memory and memprof it. But to get anything like the same level of
protection you would always have to run memprof on every code path before
you release; but to suggest that anyone will ever bother to do this for
even Gtk+ is to somewhat stretch the bounds of credulity.

>  * Finally, doing this work for GDK and GTK+ currently is wasted
> effort since much of this will fall out naturally when we do memory
> management for multi-head support correctly. If you close a display,
> then caches for the display must be freed at that point; while this
> isn't going to be _all_ cached memory, it will be a great deal of it,
> and should be virtually all objects.

        Great - well this gives me some degree of hope that we might be
able to have a sane, complete, automated test suite at some stage in the
future. Of course, ideally there would be some way for us to use the
GObject ref debugging in pure CORBA / glib apps - and yet not get 200
lines of spew when quitting a gtk+ app.

        Regards,

                Michael.

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