Ubuntu gtk leaks references in GtkTreeView / GtTreeModelSort which cause segfault in bluefish

[OlivierS]

[Impact]
<fill me in with explanation of severity and frequency of bug on users and justification for backporting the fix to the stable release>

[Development Fix]
<fill me in with an explanation of how the bug has been addressed in the development branch, including the relevant version numbers of packages modified in order to implement the fix. >

[Stable Fix]
<fill me in by pointing out a minimal patch applicable to the stable version of the package.>

[Text Case]
<fill me in with detailed *instructions* on how to reproduce the bug. This will be used by people later on to verify the updated package fixes the problem.>
1.
2.
3.
Broken Behavior:
Fixed Behavior:

[Regression Potential]
<fill me in with a discussion of likelihood and potential severity of regressions and how users could get inadvertently affected.

[Original Report]

In Bluefish we get a lot of bugreports from users on Ubuntu 11.10 that have a segfault and all backtraces have something weird: a GtkTreeModelSort is calling it's sort function after the model has been unreffed by bluefish already.

This behaviour cannot be reproduced on Fedora 16 which also has Gtk-3.2.

Checking with libgobject-list (from http://people.gnome.org/~mortenw/gobject-list.c) reveals that on Ubuntu there is a GtkTreeModelSort leaking, that is not leaking on Fedora 16.

After a gdb breakpoint g_object_ref and g_object_unref with a condition object == 0x123123123 (the pointer of the GtkTreeModelSort) and doing a backtrace for each break, I found which function does not clean it's reference count:

Breakpoint 2, g_object_ref (object=0xaebbb0) at gobject-list.c:642
642 GObject *obj = G_OBJECT (object);
#0 g_object_ref (object=0xaebbb0) at gobject-list.c:642
#1 0x00007ffff7548abd in gtk_tree_row_reference_new_proxy (proxy=0xaebbb0,
    model=0xaebbb0, path=0x1942660)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtktreemodel.c:2300
#2 0x00007ffff75dae49 in cell_info_new (accessible=0x196f820, tree_model=0xaebbb0,
    path=0x1942660, tv_col=0x746bc0, cell=0x1908dc0)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/a11y/gtktreeviewaccessible.c:3227
#3 0x00007ffff75de929 in gtk_tree_view_accessible_ref_child (obj=0x196f820, i=18)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/a11y/gtktreeviewaccessible.c:563
#4 0x00007ffff75de608 in focus_in (widget=0xaba3c0)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/a11y/gtktreeviewaccessible.c:1939
#5 0x00007ffff7456f08 in _gtk_marshal_BOOLEAN__BOXED (closure=0x1930ca0,
    return_value=0x7fffffffd640, n_param_values=<optimized out>, param_values=0x1720980,
    invocation_hint=<optimized out>, marshal_data=<optimized out>)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkmarshalers.c:85
#6 0x00007ffff61d00a4 in g_closure_invoke (closure=0x1930ca0,
    return_value=0x7fffffffd640, n_param_values=2, param_values=0x1720980,
    invocation_hint=<optimized out>)
    at /build/buildd/glib2.0-2.30.0/./gobject/gclosure.c:774
#7 0x00007ffff61e202a in signal_emit_unlocked_R (node=<optimized out>, detail=0,
    instance=0xaba3c0, emission_return=0x7fffffffd7a0, instance_and_params=0x1720980)
    at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3272
#8 0x00007ffff61eb483 in g_signal_emit_valist (instance=<optimized out>,
    signal_id=<optimized out>, detail=<optimized out>, var_args=<optimized out>)
    at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3013
#9 0x00007ffff61eb852 in g_signal_emit (instance=<optimized out>,
    signal_id=<optimized out>, detail=<optimized out>)
    at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3060
#10 0x00007ffff7584fe9 in gtk_widget_event_internal (widget=0xaba3c0, event=0x1912930)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkwidget.c:6132
#11 0x00007ffff7591492 in gtk_widget_send_focus_change (widget=0xaba3c0, event=0x1912930)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkwidget.c:14204
#12 0x00007ffff75968d0 in do_focus_change (widget=0xaba3c0, in=1)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkwindow.c:6009
#13 0x00007ffff75a2149 in _gtk_window_set_is_active (window=0x6fa170, is_active=1)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkwindow.c:9377
#14 0x00007ffff75a25ea in gtk_window_focus_in_event (widget=0x6fa170,
    event=<optimized out>) at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkwindow.c:6063
#15 gtk_window_focus_in_event (widget=0x6fa170, event=<optimized out>)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkwindow.c:6049
#16 0x00007ffff7456f08 in _gtk_marshal_BOOLEAN__BOXED (closure=0x6d5a90,
    return_value=0x7fffffffdb80, n_param_values=<optimized out>, param_values=0x1944010,
    invocation_hint=<optimized out>, marshal_data=<optimized out>)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkmarshalers.c:85
#17 0x00007ffff61d00a4 in g_closure_invoke (closure=0x6d5a90,
    return_value=0x7fffffffdb80, n_param_values=2, param_values=0x1944010,
    invocation_hint=<optimized out>)
    at /build/buildd/glib2.0-2.30.0/./gobject/gclosure.c:774
#18 0x00007ffff61e1e5f in signal_emit_unlocked_R (node=<optimized out>, detail=0,
    instance=0x6fa170, emission_return=0x7fffffffdce0, instance_and_params=0x1944010)
    at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3310
#19 0x00007ffff61eb483 in g_signal_emit_valist (instance=<optimized out>,
    signal_id=<optimized out>, detail=<optimized out>, var_args=<optimized out>)
    at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3013
#20 0x00007ffff61eb852 in g_signal_emit (instance=<optimized out>,
    signal_id=<optimized out>, detail=<optimized out>)
    at /build/buildd/glib2.0-2.30.0/./gobject/gsignal.c:3060
#21 0x00007ffff7584fe9 in gtk_widget_event_internal (widget=0x6fa170, event=0x1912bb0)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkwidget.c:6132
#22 0x00007ffff7456da3 in gtk_main_do_event (event=0x1912bb0)
    at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkmain.c:1835
#23 0x00007ffff70cf102 in gdk_event_source_dispatch (source=<optimized out>,
    callback=<optimized out>, user_data=<optimized out>)
    at /build/buildd/gtk+3.0-3.2.0/./gdk/x11/gdkeventsource.c:360
#24 0x00007ffff55a0a5d in g_main_dispatch (context=0x709090)
    at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:2441
#25 g_main_context_dispatch (context=0x709090)
    at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3011
#26 0x00007ffff55a1258 in g_main_context_iterate (context=0x709090,
    block=<optimized out>, dispatch=1, self=<optimized out>)
    at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3089
#27 0x00007ffff55a1792 in g_main_loop_run (loop=0x7fde50)
    at /build/buildd/glib2.0-2.30.0/./glib/gmain.c:3297
#28 0x00007ffff7455ecd in gtk_main () at /build/buildd/gtk+3.0-3.2.0/./gtk/gtkmain.c:1367
#29 0x0000000000422aff in main (argc=1, argv=0x7fffffffe218) at bluefish.c:402

I don't know what causes this leak. It might be Ubuntu specific patches on gtk, the gtk theme that Ubuntu is using, or accesibility settings that default to a different value on Ubuntu (both on Ubuntu and Fedora I did not change any accessibility option from the default setting).

[OlivierS (olivier-olivier)]

I filed this bug in gnome bugzilla at https://bugzilla.gnome.org/show_bug.cgi?id=669376

[Dmitry Shachnev (mitya57)]

This was fixed upstream in http://git.gnome.org/browse/gtk+/commit/?id=512ac214c68d7806bfab05f5311007169892d914, I will add this patch to Oneiric.

Can sombody please add a task for Oneiric?

[Dmitry Shachnev (mitya57)]

Attached a debdiff.

[OlivierS (olivier-olivier)]

wouldn't it be better to upgrade to Gtk+-3.2.3 instead of applying just this patch? This patch has been included in gtk+-3.2.3 aready.

I know of at least one other critical bug (that causes segfaults) that has been fixed in gtk+-3.2.3.

[Chris Halse Rogers (raof)]

That commit message does not exactly inspire confidence ☺.

Can we please get a SRU request roughly following https://wiki.ubuntu.com/StableReleaseUpdates#Procedure ? In particular - how widespread is this problem, and what's the regression-potential?

[OlivierS (olivier-olivier)]

That commit is part of gtk-3.2.3 which is distributed in other releases (for example Fedora) already. In Fedora there are no stability issues found any more. Also on the bluefish side we do not receive any segfault messages from Fedora users, only from Ubuntu users. So from my point of view there seems to be no regression.

The issue is relevant to any application that uses a GtkTreeModel with a GtkTreeView widget, and the GtkTreeView widget is destroyed but the GtkTreeModel is not (for example because multiple GtkTreeView widgets use the same GtkTreModel).

[Evan Broder (broder)]

The commit message certainly leaves a lot to be desired. On the one hand, the commit is definitely fixing a bug in the reference tracking of the info struct, and it avoids storing pointers to the stack which are almost immediately invalidated. On the other hand, while I would expect either of those bugs to cause crashes, I don't see how either of those bugs could affect whether or not there's an extra reference to the GtkTreeModelSort - causing the crash that Olivier describes - but that may just be because of my weak understanding of the whole GtkTree* set of classes.

I'm personally not willing to sponsor this into the archive proper without a better sense of whether or not it will fix the bug at hand.

Olivier: Do you have a concise set of instructions on how to reproduce the bug using Bluefish?

For the time being, I'm going to upload the patch to my PPA (https://launchpad.net/~broder/+archive/ubuntu-tests). If somebody can show me some evidence that this particular patch fixes this particular bug, I'd be happy to upload the change.

[Sebastien Bacher (seb128)]

Dropping from the queue, Evan seems to be on it

[OlivierS (olivier-olivier)]

With valgrind it is easy to spot with a bluefish binary compiled with gtk-3 (bluefish-2.2.1 compiled with gtk+-3.0-dev available).

you will get an invalid memory access if you just open the preferences and close it with 'OK'.

without valgrind it is harder to spot because it corrupts memory which may or may not result in crashes.

[Dmitry Shachnev (mitya57)]

Unassigning from myself as there's nothing else I can do here. A debdiff, ready for sponsoring, is attached.

[Sebastien Bacher (seb128)]

> Unassigning from myself as there's nothing else I can do here. A debdiff, ready for sponsoring, is attached.

Thanks for the work, I've sponsored the update

[Rolf Leggewie (r0lf)]

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".