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