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 _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
