GNOME Bugzilla – Bug 794542
Fails to render menus toolbars dialogs
Last modified: 2018-05-22 14:36:39 UTC
Created attachment 369928 [details] super small work book that stops gnumeric from rendering menus toolbars dialogs Thanks again for maintaining gnumeric. I'm happy to present 1.) A super small work book that stops gnumeric from rendering its menus toolbars dialogs every time. At least for me. 2.) A video showing the bug happening, with an over-the-top sound track! Both are attached. It seems to me one bug begat another. 1.) The first bug corrupted the work book's cell A1. I don't know how to elicit this bug. 2.) That corruption elicits a second bug. It stops gnumeric from rendering menus toolbars dialogs. The attached video shows it happening with the attached super small work book. Other cells were corrupted too. One had data that looked like 3 entire rows, including "`" (back tick) characters that I often use as a delimiter when importing and exporting from and to text files. I don't know what caused this corruption either. Thanks again for maintaining gnumeric. I look forward to seeing a fix. So, Kingsley
Created attachment 369929 [details] Video showing the bug happening
I am unable to replicate the problem. The file opens just fine for me without any non-rendered user interface items.
Created attachment 369942 [details] Video of mouse pointer painting (some!) menus toolbars dialogs Andreas: Thanks for trying. All: Here's a video showing how scrubbing the mouse pointer over menus toolbars dialogs causes (some of) them to be painted. At least on my computer. So, Kingsley
I can reproduce. Very strange.
Actually the bug occurs when the file is opened from the command line, but not if it is open in an already running gnumeric instance, at least for me.
Looks related to the filter. I tried to remove it, but it is back when the file is reopened, so we have another, probably unrelated bug. If I remove the filter using a text editor, the bug does not show up anymore.
I don't see it. And I see no valgrind events.
FWIW, Andreas and I typically run with fairly old Gtk+ and Jean with newer.
I saw the bug with these versions of debian Gtk+ packages: gir1.2-keybinder-3.0 0.3.1-1 and 0.3.2-1 libchamplain-gtk-0.12-0:i386 0.12.16-2 libkeybinder-3.0-0:i386 0.3.1-1
Created attachment 369999 [details] [review] initial patch Gtk+-3.22 is most probably the culprit. The issue comes from the drawing of the filter arrow. No idea why. Replacing the deprecated (one more) GtkArrow by a GtkImage does not help, but using a GtkLabel with an appropriate arrow character is an efficient workaround. May be we might develop our own arrow widget instead?
It is highly worrying that an image doesn't work. That suggests that we really don't understand the issue and that it will bite us again in some other form.
I like gnumeric and agree with Morten's concern. I found more corruption, will describe it, and humbly suggest how we might proceed. MORE CORRUPTION About 50 of 24,000 rows had corrupt data appended in bogus columns beyond their normal ends. It looked like repeated excerpts of data normally found in other columns. HOW WE MIGHT PROCEED Maybe we could use the "diff" utility to compare gdb and/or strace logs from installs that fail and work. Evidently Jean and I can elicit the bug, and could log it happening and Morton and Andreas have working installs, so they could log gnumeric working correctly. So, Kingsley
Created attachment 370332 [details] A simple file showing the issue I can reproduce the bug with no data at all, just a filter. So it is not related to corrupt data. It is just a Gtk+ issue. I checked the cairo status after drawing the widget, but it does not show any error.
Yes, but, I didn't intentionally add the filter. I'm worried that the same bug that corrupted data also added a filter. Sorry. So, Kingsley
If you want to get rid of that filter in your file, then just do... 1. gunzip <foo.gnumeric >foo.xml 2. edit foo.xml and remove any gnm:Filters sections. 3. gzip <foo.xml >bar.gnumeric Note: keep the old file around, just in case. If I understand the tea leaves correctly, that should bring the file to a state where the rendering issue disappears. You can then assess whether you have data corruption. If you do, the best thing really is to go back to a know-ok backup. I am not sure how a filter would show up as a result of memory corruption. The syntax isn't something you get by changing just a few bytes randomly. Someone poking around in an all-grey UI could cause it, but as I understand it that's the wrong ordering. With respect to comparing stack traces/strace logs I don't think that will help us. It will say that things are different but we know there are thousands of changes in gtk+, so telling which one is wrong is going to be hard. Unless we can do git bisection. Jean: are you setup to do that?
I just don't know what is git bisection.
It's git's tool for finding what [gtk+ commit] introduced the problem. "git bisect --help" has details. What it really requires is that you are set up to run with a self- compiled version of gtk+, at least in the range of 3.20 to 3.22 That's backwards for you so you probably don't have to update any of the dependencies. Basically you find a "good" version and a "bad" version whereupon git guides you to test further versions in an efficient way.
The issue is already there with 3.20, and I'm unable to build older versions.
I was wrong in the morning, apparently I did not properly uninstalled a buggy version. 3.20.0 works as expected.
git bisect found the first bad commit: https://git.gnome.org/browse/gtk/commit/?h=gtk-3-22&id=ddcf47026dbbe58dca3b34c7bb1ec63bb50a861a
That commit was intended to fix bug 765700 which also hit Gnumeric...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/336.