Re: Refdbg and GObject 2.6.x

[Matthias Clasen <mclasen redhat com>]

On Mon, 2005-01-24 at 20:26 -0800, Josh Green wrote:
> On Mon, 2005-01-24 at 14:58 -0500, Matthias Clasen wrote:
> > On Mon, 2005-01-24 at 11:44 -0800, Josh Green wrote:
> > > On Mon, 2005-01-24 at 13:50 +0100, David Necas (Yeti) wrote:
> > > > On Mon, Jan 24, 2005 at 12:07:58AM -0800, Josh Green wrote:
> > > > > Hello, I'm the author of refdbg (http://refdbg.sourceforge.net), a
> > > > > GObject reference count debugger.  Recently a user notified me that it
> > > > > doesn't work with glib 2.6.x.  Refdbg works by using LD_PRELOAD to
> > > > > override the following functions in GObject:
> > > > > 
> > > > > g_object_newv
> > > > > g_type_free_instance
> > > > > g_object_ref
> > > > > g_object_unref
> > > > > 
> > > > > It seems with glib 2.6.x the first two functions (g_object_newv and
> > > > > g_type_free_instance), do not get overridden, while g_object_ref/unref
> > > > > do.  I was hoping that someone could give me some hints on why this is
> > > > > happening.  Tips on debugging the LD_PRELOAD process or a better method
> > > > > of catching calls to these functions would also be appreciated.
> > > > 
> > > > I'm afraid calls to these functions inside GLib itself
> > > > cannot be overriden by LD_PRELOAD (or any other run-time
> > > > method) any more.  See
> > > > 
> > > >     http://bugzilla.gnome.org/show_bug.cgi?id=145519
> > > > 
> > > > for discussion.
> > > > 
> > > > Calls to the latter two usually appear outside GLib (in Gtk+
> > > > or user code) while to the former two inside GLib itself --
> > > > this explains the observed difference.
> > > > 
> > > > Yeti
> > > > 
> > > 
> > > Thank you for that information, very informative.  I suppose refdbg will
> > > need to override g_object_new, g_object_new_valist and g_object_newv for
> > > the 2.6.x versions in order to be complete.  Unfortunately I don't see a
> > > way to determine when an object is actually finalized (I was using
> > > g_type_free_instance).  So I suppose it will have to rely on
> > > g_object_unref which is problematic, since ref/unref activity may occur
> > > in the finalize callback which might lead to the object not being
> > > destroyed or refdbg thinking the reference activity is erroneous when in
> > > fact it is valid.  If anyone has some ideas on how to handle this
> > > (determining when an object is actually freed), I would appreciate the
> > > info.  Thanks again.
> > > 	Josh Green
> > 
> > As pointed out by Yeti, it is not really possible to replace
> > g_object_new and friends completely by ld preload tricks in 2.6 anymore.
> > Internal calls in libgobject will not go through your ld preloaded
> > replacements.
> > 
> > Matthias
> > 
> 
> Ahhh, I didn't get that the first time.  Thanks for the clarification,
> although I'm somewhat unhappy to hear that.  I guess thats the trade off
> for speed.  So refdbg can't support gobject 2.6.x then and developers
> will need to use gobject 2.4.x in order to debug their programs.  Ahh
> well, thats the way it goes.  Any possibility that there could be a
> build time option of making it possible to hook these functions or are
> there other reference count debuggers out there or anything built in to
> gobject that would aid the developer in this often complicated task?
> 	Josh Green


If you configure glib with --disable-visibility, the internal aliases
are not created, which should allow refdbg to function as it did in
2.4.x.

Matthias