For years and years I’ve dreamt of a tool that would show me what GObjects are currently alive, and let me have a look at information about them. Today, while trying to debug a particularly horrid reference leak (program wedged under refdbg, and without being able to script SIGTRAP I’ve never found this method useful), I actually started writing the tool.
The tool uses LD_PRELOAD to replace g_object_new() — it should really replace g_object_newv() and g_object_new_valist() also, but I didn’t need those — to install a weak reference on the created objects to track their lifetime.
The result of which is something like this:
[danni@adelie src]$ LD_PRELOAD=libgobject-list.so \
GOBJECT_LIST_FILTER=Gabble GABBLE_PERSIST=1 \
++ Created object 0x9912530, GabbleGatewayPlugin
++ Created object 0x990c460, GabblePluginLoader
++ Created object 0x9917ab8, GabbleJabberProtocol
++ Created object 0x99172f0, GabbleConnectionManager
You can then list the currently living objects and their reference counts by sending SIGUSR1.
[danni@adelie src]$ killall -USR1 telepathy-gabble
- 0x9b47038, GabblePresence: 1 refs
- 0x990c460, GabblePluginLoader: 2 refs
- 0x9918ae0, GabbleRosterChannel: 1 refs
- 0x991cb38, GabbleIMChannel: 1 refs
This by itself was useful in showing which object wasn’t finalized but should have been (and why my object in question also hadn’t finalized), but didn’t show me who was still holding the reference.
My hunch was that the problem was a reference cycle between two objects, so I hacked a bit of code into my tool to list the “connection” property on all objects that had it. [In Telepathy Connection Managers, objects are typically meant to let this go when connections become disconnected.]
while (g_hash_table_iter_next (&iter, (gpointer) &obj, NULL))
g_print (" - %p, %s: %u refs\n",
obj, G_OBJECT_TYPE_NAME (obj), obj->ref_count);
klass = G_OBJECT_GET_CLASS (obj);
if (g_object_class_find_property (klass, "connection") != NULL)
g_print ("\t + connection = %p\n", conn);
if (conn != NULL)
This showed me which object was still holding a ref it should have let go. [Now I just need to work out why, the code in question is in an abstract base class, for which 5 of 6 concrete classes work correctly.]
If you’re interested, the code is in Git.
The tool could still benefit from a lot of work. For instance, the filtering is pretty basic at the moment and it should support all the ways to create GObjects. Originally I had envisioned this tool as a GUI window that popped up, so that you could click on an object and view all of its properties, connected signals, etc. That would be pretty neat actually.
Update: cassidy has already contributed by adding a listing of the objects remaining when a program exits and thus found a leak in Empathy. Awesome!