Re: More explanation of g_blow_caches / g_debug_shutdown
- From: Tim Janik <timj gtk org>
- To: Michael Meeks <michael ximian com>
- Cc: Owen Taylor <otaylor redhat com>, Gtk Hackers <gtk-devel-list gnome org>
- Subject: Re: More explanation of g_blow_caches / g_debug_shutdown
- Date: Tue, 13 Nov 2001 00:19:45 +0100 (CET)
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]