GNOME Bugzilla – Bug 119635
crash adding GtkCList
Last modified: 2004-12-22 21:47:04 UTC
I'm using GLADE 2.0.0, libglade 2.0.1, GTK+ 2.2.1, GLib 2.2.1, and GAIL 1.2.0 on Linux. GLADE crashes if I add a GtkCList or GtkCTree to a GtkScrolledWindow that previously held a GtkTreeView. I can reproduce this every time with the following steps: 1. start a new GTK+ project 2. add a GtkWindow 3. add a GtkTreeView to the window 4. delete the GtkTreeView, but not the automatically added GtkScrolledWindow 5. add a GtkCList or GtkCTree I'm attaching a backtrace.
Created attachment 19108 [details] GDB backtrace with some Red Hat debuginfo packages installed
The following appears on stderr if I start GLADE from a terminal session: GTK Accessibility Module initialized (glade-2:29534): Gtk-WARNING **: gtk_scrolled_window_add(): cannot add non scrollable widget use gtk_scrolled_window_add_with_viewport() instead (glade-2:29534): Gtk-WARNING **: gtk_scrolled_window_add(): cannot add non scrollable widget use gtk_scrolled_window_add_with_viewport() instead (glade-2:29534): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkWidget' (glade-2:29534): Gtk-CRITICAL **: file gtkwidget.c: line 6791 (gtk_widget_get_accessible): assertion `GTK_IS_WIDGET (widget)' failed GTK Accessibility Module initialized
Yes, I can reproduce. The crash appears to be in gail, though, so I'll move the bug to atk (I can't find a gail product). I think the problem is that gailtreeview.c doesn't disconnect the signal handlers from the scrolled window adjustments when it is destroyed. So the signal handlers are still called, but the treeview is not valid any more.
Created attachment 20737 [details] [review] Patch for gail
The attached patch for gail prevents the problem from occurring. However it looks to me that the real problem is in glade-2 or gtk. I will attach a stack trace that shows that gtk_tree_view_set_adjustment() is called with hadj and vadj set to NULL when the GtkTreeView is deleted. This causes new vertical and horizontal adjustments to be created and silently replace the existing ones. It also seems that the new adjustments are then leaked. My patch to gail saves the original hadj and vadj so that I can remove the signal handlers. This does not seem like the correct solution.
Created attachment 20738 [details] Stack trace of glade-2
*** Bug 118139 has been marked as a duplicate of this bug. ***
I agree there could be a problem in GTK+ here as well. But I don't think Glade is involved. I think all Glade did was remove a GtkTreeView and put a GtkCList in its place. I don't really know how you handle life-cycle issues in gail so I can't really help much with that. What sort of better solution did you have in mind?
Actually gailtreeview.c doesn't seem to be taking into account the fact that the treeview adjustments are changed when it is added to a scrolledwindow. Or by using gtk_tree_view_set_hadjustment(). So that may need fixing as well. (Unless I missed something.) I really think this should be an atk bug ;)
Thanks for your work at this. I have looked at this some more and I accept that this is a gail bug.
Created attachment 20814 [details] [review] Updated patch for gail
atch committed to CVS HEAD.
*** Bug 125761 has been marked as a duplicate of this bug. ***
*** Bug 126059 has been marked as a duplicate of this bug. ***
*** Bug 130538 has been marked as a duplicate of this bug. ***