GNOME Bugzilla – Bug 94812
deleting a gtkclist row in extended mode and using shift-up crashes gtk+
Last modified: 2011-02-04 16:11:52 UTC
Near line 2804 of the current GTK gtkclist.c file, there is some (partially broken, commented out) code. I have "fixed" the code: if (clist->focus_row >=0 && (row <= clist->focus_row || clist->focus_row >= clist->rows)) clist->focus_row--; if (clist->focus_row < 0) clist->focus_row = 0; Why? Take a CList, set the mode to EXTENDED. attach a signal handler for control-d that deletes the currently selected rows (after sorting and reversing, so we delete down->up). Populate the clist with some data. select the last row. hit control-d. Here is the bug: the focus_row is 1 greater than the number of rows. Still using the keyboard, hold down shift and tap up-arrow. release shift. *bang*, sigseg. it also works if you select multiple rows, just so long as the last row highlighted is the last row. There are also reported problems with going the other direction (ie, selecting "up", but I've been unable to reproduce that problem.) This is reproduceable 100% of the time. The backtrace looks like this:
+ Trace 28227
The last line of the patch: if (clist->focus_row < 0) clist->focus_row = 0; if not actually needed. I was afraid of setting it to -1, but apparently that is a valid value.
How does this relate to bug 81884? Did you forget to attach a patch?
Not enough information here. Please reopen if you add more information. (A small standalone compilable test case is also always appreciated)
It may be related to bug 81884, but the problem is that is causes a segfault. Would you accept a test program using PyGTK or must it be in C?
We'd really prefer a test case in C if possible; it's much harder to debug a PyGTK program even if the person working on this has PyGTK compiled against the right version of GTK+.
Created attachment 11807 [details] [review] A patch to CList that helps prevent some segmentation faults
I added the attachment patch. If asked, I can also attach a PyGTK test program. If necessary, I can try to make a C version as well.
Please at least attach the Python test case, since it will give an exact idea of the sequence of events involved here, and allow creating a C test program. A C test case would allow us to easily verify whether this is a GTK+-1.2 specific bug or a bug in the current code as well, so would be appreciated, but is not necessary. (To be frank, GtkCList bugs get low priority these days, so I'm not sure when we'll get to this one.)
Created attachment 11811 [details] A PyGTK program to demonstrate the bug
BTW, Owen -- if you like the patch but can't release or won't release a new gtk+, what's the likelihood of getting the patch into the RedHat packages?
Every bug fix that goes into the GTK+-2.0 Red Hat RPMS also goes upstream. We do have non-upstream bugfixes for our GTK+-1.2 packages in Red Hat. (Because there aren't any more upstream release being planned at this point. )But it is very unlikely that we'll be do any bug fixes for them at this point unless the bug occurs in an application we ship upstream.
Owen, can this please be fix in GTK+-1.2? We use GTK+ and PyGTK in the application our company develops, and there should be no reason why a new stable release should be done if bugs are actively being found and fixed.
The problem is that the combination of a person with the time, interest, and knowledge to do another 1.2.x release doesn't exist.
Well.. John, we can try putting a band-aid fix into PyGTK-0.x, which I hate but seems the only thing I can do at the moment. Do you think you can work out a patch that can fit nicely into 0.6 CVS HEAD?
Why do you feel it would be a band aid? The patch appears to do the "right thing" -- it fixes a bug. As for doing a release, I certainly don't have time for it, wouldn't know how anyway. It's not a huge deal for me personally, but there are **lots** of people that still use gtk0 (gtk1?) and as such, new "maintainence" releases should continue to be made until an easier transition to gtk2 can be made. Just how compatible with gtk2 is most gtk1 code? Galeon and Mozilla are huge codebases, and seem to be taking a long time. I don't mind much because they are so cool, but even very small programs aren't being ported. Why is this?
Created attachment 12955 [details] C translation of test case
Created attachment 12958 [details] [review] Attempt at a patch
The code that you commented back in was commented out when the logic to deal with updating the focus row was moved to the sync_selection() function. (looking at CVS history) My patch fixes up the sync_selection() function rather than restoring the commented out code.
Fri Dec 13 23:10:21 2002 Owen Taylor <otaylor@redhat.com> * gtk/gtkclist.c: Fix a problem with the focus row ending up off the list when rows were deleted (#94812, Christian Reis, Jon Nelson). [ Committed to all three branches, though I don't expect another release for either of the old ones... ]
*** Bug 81884 has been marked as a duplicate of this bug. ***