Comment 13 for bug 1438014

Revision history for this message
yzp15 (yzp15) wrote :

Hello. I had some debugging with valgrind and gdb for the error with stacktrace top

 g_type_check_instance_is_a glib2.0-2.43.92/./gobject/gtype.c:4016
 gtk_widget_get_toplevel gtk+3.0-3.14.9/./gtk/gtkwidget.c:11382
 window_group_cleanup_grabs gtk+3.0-3.14.9/./gtk/gtkwindowgroup.c:110
 gtk_window_group_add_window gtk+3.0-3.14.9/./gtk/gtkwindowgroup.c:169
 gtk_window_set_transient_for gtk+3.0-3.14.9/./gtk/gtkwindow.c:3134

This is use-after-free due to incorrect grab deregistration (gtk_grab_remove tries to remove the grab not from the same window_group where it was added by gtk_grab_add)
Results were posted to Bug #1667227 and Bug #1667232
https://bugs.launchpad.net/ubuntu/+source/mate-terminal/+bug/1667227 and https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1667232

I think that gnome-terminal grab use-after-free after editing keyboard shortcuts may be not related to the patch "debian/patches/016_no_offscreen_widgets_grabbing.patch" (it only helps to report Critical to the log).

Both gtk_grab_add and gtk_grab_remove calls gtk_main_get_window_group function, but it returns different results for these two calls (more details at https://bugs.launchpad.net/ubuntu/+source/mate-terminal/+bug/1667227/comments/8)

static GtkWindowGroup *
gtk_main_get_window_group (GtkWidget *widget)
...
  if (GTK_IS_WINDOW (toplevel))
    return gtk_window_get_group (GTK_WINDOW (toplevel));
  else
    return gtk_window_get_group (NULL);

At the time of gtk_grab_add (called from gtk_cell_renderer_accel_start_editing which is called from gtk_cell_renderer_start_editing) this widget had window = 0x0 and parent = 0x0
And at time of gtk_grab_remove (called from gtk_cell_editable_event_box_key_press_event) same widget had window = 0x555555e507e0 (parent = 0x555555e183f0) which leads to incorrect deregistration of the grab.

Parent of the widget was changed by gtk_tree_view_multipress_gesture_pressed -> .. -> gtk_cell_area_activate_cell -> gtk_cell_area_add_editable -> ..signal.. -> gtk_tree_view_column_add_editable_callback -> _gtk_tree_view_add_editable -> gtk_tree_view_put -> gtk_widget_set_parent

So, gtk_cell_area_activate_cell of gtk+3 (3.22.7) has some kind of incorrect ordering of actions which broke gtk_grab_add / gtk_grab_remove pair
https://github.com/GNOME/gtk/blob/6cc08d60efeb02afc0d67982c3dc205dfd16d7cd/gtk/gtkcellarea.c#L3388

3428 gtk_cell_renderer_start_editing (renderer,
...
3444 gtk_cell_area_add_editable (area, priv->focus_cell, editable_widget, cell_area);

(There was also quick and probably incorrect fix in Bug #1667227 for this use-after-free with additional removing of grab from gtk_window_get_group (NULL) https://launchpadlibrarian.net/308873213/lp1667227_quick_fix_gtk_grab_remove.gtk+3.22.8.patch )