Re: the pros of gtk_debug_shutdown

[Tim Janik <timj gtk org>]

On Fri, 9 Nov 2001, Skip Montanaro wrote:

>     Michael> Here are some of the pros and cons of having a _debug_shutdown
>     Michael> method:
> 
> (Once again, I chime in even though I plead ignorance of the source. ;-)
> 
> I'm not saying yea or nay on the idea of a debug_shutdown method, just
> trying to see if there's a way you can use the facilities gtk currently
> provides to see if your applications are leaking.
> 
> It seems clear that you can dump out the reference counts at the end of the
> program.  In the absence of a debug_shutdown method can you perhaps dump the
> reference count information immediately after calling gtk_init and then zap
> those objects from the dump at the end?  Presumably stuff like the root
> window wrapper and static GdkVisuals will have been allocated at that point.
> 
> Also, if there is a function you can call to dump refcounts during the
> program's run, couldn't you call it periodically as well, to see how the
> information changes as you perform various actions?  If you're leaking
> widgets, you should see the number grow (or the reference count of one or
> more widgets increase) as the leak-causing action is repeated during what
> should be steady state operation.

the dumps currently only occour ala atexit(dumpfunc);
void dumpfunc() { forall o in objects { g_print(o); } }
i.e. you can't actually _call_ it, and certainly not get the
objects enlisted in e.g. a GSList.
this would produce quite some problems btw, i.e. say you do:

/* prg start */
slist1 = g_object_list_stale_refs ();
/* some program action going on */
slist2 = g_object_list_stale_refs ();
forall node in slist2 { if (!contained (slist1, node)) g_print (node->data); }

then an object contained in slist1 could have been freed, and later
its memory space gets reused for another new object. that new object
would be skipped during your printout.

---
ciaoTJ