GNOME Bugzilla – Bug 671939
[regression] crash on exit
Last modified: 2013-03-13 01:08:26 UTC
I'm running gnumeric-1.11.2 on a gnome-3.3.91 installation (in particular, this means I'm running with glib-2.31.20 and gtk+-3.3.18). Gnumeric works more or less as expected, but crashes if I close a window the crtl-w or exit with ctrl-q. Here's a backtrace: Program terminated with signal 11, Segmentation fault.
+ Trace 229857
Thread 1 (Thread 0xb5f5a7f0 (LWP 8687))
One other observation. I see this in other apps as well (e.g., gnome-panel) and suspect that this is not just a gnumeric issue.
I don't see the crash, probably related to gtk+-3.3.x.
You are running an experimental version of GTK and observing the same problem in other programs. So this bug should really be filed against GTK.
*** Bug 674906 has been marked as a duplicate of this bug. ***
FWIW the latest gnumeric/goffice (1.11.3/0.9.3) don't have this problem.
Morten has committed a workaround to Gnumeric 1.11.3 that tries to avoid hitting this bug in gtk. So the fact that gnumeric/goffice (1.11.3/0.9.3) does not show this crash does not mean that there is no problem in gtk.
This is also discussed at https://bugzilla.redhat.com/show_bug.cgi?id=803904
*** Bug 675984 has been marked as a duplicate of this bug. ***
Patch available in bug 679291 - please review/commit.
*** Bug 679291 has been marked as a duplicate of this bug. ***
this bug should have been marked as a dupe of 679291, seeing that the other one has a patch - even if this one has a stack trace. anyway, the patch in attachment 217892 [details] looks okay - but what I'd like to see: a) bisecting to see what commit broke this; b) a test case for the TreeView test suite, to ensure we don't regress again; c) a patch done using git format-patch or git bz, so that we can credit the author. John, would you be so kind to look at this? that would be stellar.
Copying Matthias's comments from his email: > The behaviour change was introduced during the heavy refactoring of > treeview a11y done by Benjamin last winter. We've talked about > 'fixing' this (ie suppressing the signal in the destroy path), but > there's a more general question here: do we want to add tons of > special-cases to prevent this kind of noise in destroy paths ? There's > plenty of other places where this could happen. So my efforts here are not wanted, it seems. "It's not a bug, it's a behavior change."
(In reply to comment #12) > Copying Matthias's comments from his email: > > > The behaviour change was introduced during the heavy refactoring of > > treeview a11y done by Benjamin last winter. We've talked about > > 'fixing' this (ie suppressing the signal in the destroy path), but > > there's a more general question here: do we want to add tons of > > special-cases to prevent this kind of noise in destroy paths ? There's > > plenty of other places where this could happen. > > So my efforts here are not wanted, it seems. "It's not a bug, it's a behavior > change." no: it's still an open question.
Well, if you decide to leave it the way it is, then you will need to update the documentation for the "cursor-changed" signal and for gtk_tree_view_get_selection(): cursor-changed: "The position of the cursor (focused cell) has changed, or the GtkTreeView object is being destroyed." gtk_tree_view_get_selection: "Returns the GtkTreeSelection associated with tree_view, or NULL if tree_view is being destroyed." And you will need to add lots of "noise" to the documentation in "plenty of other places" also. Which will make life harder for anyone wanting to use GTK+, because then *they* have to look out for all these special cases. To me, that seems just stupid. But what do I know? I don't develop GTK+, I only use it.
(In reply to comment #14) > To me, that seems just stupid. But what do I know? I don't develop GTK+, > I only use it. you can also assume that the people interacting with you are not stupid. please refreain from making comments like this in the future; Bugzilla, like the mailing lists hosted on gnome.org, falls under the Code of Conduct, which you can find on the wiki: https://live.gnome.org/CodeOfConduct
I'd like to see widgets taking care of it. This is based on the assumption that apps_using_gtk >> widgets_in_gtk.
Applied the patch from bug 679291.