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
Attachment:
signature.asc
Description: This is a digitally signed message part