Posts Tagged ‘gtk+’

Statuses

Debugging a reference count bug

In Bluefish,gtk+,open source,Programming,Ubuntu on February 5, 2012 by oli4444 Tagged:

Last days I have been debugging some weird reports. They all show the same characteristics:

  • the users are on Ubuntu 11.10
  • they use bluefish compiled against gtk 3.2 (so not the bluefish package that is provided by Ubuntu, but a newer one)
  • in the Bluefish run the sort function of a GtkTreeModelSort is called after the GtkTreeModelSort should have been finalized and free’ed.

First I used gobject-list.c from http://people.gnome.org/~mortenw/gobject-list.c to see all refs and unrefs on all GtkTreeModelSort objects in Bluefish (luckily there is only 1 used in Bluefish).This showed that there was indeed a GtkTreeModelSort with lots of references left after it should have been finalized. I tried the same thing on Fedora 16 (also gtk-3.2), but it can only be reproduced on Ubuntu 11.10.I tried to get backtraces with gobject-list (which uses libunwind for that) but those backtraces turned out to be useless.

Luckily I received some help on IRC #gtk+ from Company and alex. The first idea was to use systemtap, but since there is no useful kernel for systemtap available for Ubuntu I had to use something more low tech suggested by Company:  I set a breakpoint on gtk_tree_model_sort_new to retrieve the pointer of the GtkTreeModelSort. Once I got that pointer I could set a breakpoint on g_object_ref and g_object_unref with a condition on this pointer. Then I created an automatic backtrace on each breakpoint:

break g_object_ref if object == 0x123123123
commands
bt
c
end

I configured gdb to log everrything to a file, and did a bluefish run. This resulted in a 2.1 Mb logfile with backtraces. This log also showed there were more refs than unrefs.

In this logfile there were a lot of similar backtraces, with an identical function doing a ref and an unref. I wrote a short python script to parse the backtraces and skip all ‘valid pairs’

After this step I had only 15 backtraces left. And from these backtraces the leaking references were easily identified.

Because I was unsure if this is a Ubuntu specific bug or a generic gtk bug the resulting bugreport can be found both at https://bugzilla.gnome.org/show_bug.cgi?id=669376 and at https://bugs.launchpad.net/bugs/926889

Now I am wondering if this approach would work for any reference count leaking problem. I guess the most difficult issue is to find the value of the pointer that is leaking if you have many objects of the same type.. Any suggestions how to do this?

Advertisements