Re: More explanation of g_blow_caches / g_debug_shutdown



On Sun, 11 Nov 2001, Michael Meeks wrote:

> Hi Tim,
> 



> > 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;

i am, actually i got
export GTK_DEBUG=objects GDK_DEBUG=misc GRUNTIME_DEBUG=objects GTK_MODULES=gle
in my .profile ;)

>         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.

well, say we introduced:
#ifdef G_ENABLE_DEBUG
guint g_object_get_n_alive_objects (void);
#endif

would that be enough for you?

> > 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 ).


>         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 ...


well, this is going to be a normal public API call then, say something like:

void gtk_blow_caches (void);
void gdk_blow_caches (void);
/* pango, anyone? */
void g_blow_caches (void);

and all of them chaining down.

the name is not so important however, the implementation is what needs
hard work ;)

> > - 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 ?

i made some suggestions above, but i want to talk this over with owen once
i catch him on irc. he tends to have his own mind about allocation issues
anyways, and we might put a few more thoughts into this to ensure we don't
screw up our API last minute ;)

> 
>         Regards,
> 
>                 Michael.

---
ciaoTJ




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]