Tracking GObjects

I stated before, that you have to release all OpenCL resources to prevent leaking buffer memory and eventually crashing the application. Now, it hit me again but wrapped in a GObject.

I didn’t know where exactly the problem was located but I suspected that a GObject wasn’t properly unreferenced and in the end finalized, hence leaking OpenCL resources. I knew there was a project to keep track of GObject references but I forgot the name.

Eventually, I found gobject-list again thanks to my Google super powers. Not only that, but it also helped debugging the problem in question. Now, what is gobject-list? It is a small library that is pre-load when running the application:

 ++ Created object 0x1ee3800, UfoConfig
 ++ Created object 0x1ee3840, UfoPluginManager
 ++ Created object 0x1ee5810, UfoResources

The library intercepts calls to g_object_new, g_object_ref and g_object_unref and logs them. By sending SIGUSR1 to the application, alive objects and reference counts can be queried:

$ killall -USR1 app
Living Objects:
 - 0x1ee5810, UfoResources: 1 refs
 - 0x1ee3800, UfoConfig: 3 refs
 - 0x1ee3840, UfoPluginManager: 1 refs

More details can be found in the blog post by the original author. Big props to her!


Post a comment

Name required

E-mail required, not published

Website optional

Comment Markdown accepted