Re: Refdbg and GObject 2.6.x

[Matthias Clasen <mclasen redhat com>]

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