After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794542 - Fails to render menus toolbars dialogs
Fails to render menus toolbars dialogs
Status: RESOLVED OBSOLETE
Product: Gnumeric
Classification: Applications
Component: GUI
1.12.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2018-03-20 22:30 UTC by Kingsley G. Morse Jr.
Modified: 2018-05-22 14:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
super small work book that stops gnumeric from rendering menus toolbars dialogs (5.90 KB, application/x-gnumeric)
2018-03-20 22:30 UTC, Kingsley G. Morse Jr.
  Details
Video showing the bug happening (2.74 MB, video/webm)
2018-03-20 22:40 UTC, Kingsley G. Morse Jr.
  Details
Video of mouse pointer painting (some!) menus toolbars dialogs (2.62 MB, video/webm)
2018-03-21 04:20 UTC, Kingsley G. Morse Jr.
  Details
initial patch (970 bytes, patch)
2018-03-22 10:29 UTC, Jean Bréfort
none Details | Review
A simple file showing the issue (4.75 KB, application/x-gnumeric)
2018-03-30 08:31 UTC, Jean Bréfort
  Details

Description Kingsley G. Morse Jr. 2018-03-20 22:30:50 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
Comment 1 Kingsley G. Morse Jr. 2018-03-20 22:40:21 UTC
Created attachment 369929 [details]
Video showing the bug happening
Comment 2 Andreas J. Guelzow 2018-03-21 03:11:08 UTC
I am unable to replicate the problem. The file opens just fine for me without any non-rendered user interface items.
Comment 3 Kingsley G. Morse Jr. 2018-03-21 04:20:47 UTC
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
Comment 4 Jean Bréfort 2018-03-21 07:01:19 UTC
I can reproduce. Very strange.
Comment 5 Jean Bréfort 2018-03-21 07:27:51 UTC
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.
Comment 6 Jean Bréfort 2018-03-21 07:38:06 UTC
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.
Comment 7 Morten Welinder 2018-03-21 14:52:24 UTC
I don't see it.  And I see no valgrind events.
Comment 8 Morten Welinder 2018-03-21 14:53:37 UTC
FWIW, Andreas and I typically run with fairly old Gtk+ and Jean with
newer.
Comment 9 Kingsley G. Morse Jr. 2018-03-21 16:36:19 UTC
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
Comment 10 Jean Bréfort 2018-03-22 10:29:19 UTC
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?
Comment 11 Morten Welinder 2018-03-23 15:46:22 UTC
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.
Comment 12 Kingsley G. Morse Jr. 2018-03-29 20:58:02 UTC
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
Comment 13 Jean Bréfort 2018-03-30 08:31:14 UTC
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.
Comment 14 Kingsley G. Morse Jr. 2018-03-30 19:47:06 UTC
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
Comment 15 Morten Welinder 2018-03-30 20:26:11 UTC
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?
Comment 16 Jean Bréfort 2018-03-31 06:30:21 UTC
I just don't know what is git bisection.
Comment 17 Morten Welinder 2018-03-31 14:47:31 UTC
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.
Comment 18 Jean Bréfort 2018-04-01 09:19:49 UTC
The issue is already there with 3.20, and I'm unable to build older versions.
Comment 19 Jean Bréfort 2018-04-01 13:41:06 UTC
I was wrong in the morning, apparently I did not properly uninstalled a buggy version. 3.20.0 works as expected.
Comment 20 Jean Bréfort 2018-04-01 18:57:56 UTC
git bisect found the first bad commit: 

https://git.gnome.org/browse/gtk/commit/?h=gtk-3-22&id=ddcf47026dbbe58dca3b34c7bb1ec63bb50a861a
Comment 21 Morten Welinder 2018-04-01 19:07:53 UTC
That commit was intended to fix bug 765700 which also hit Gnumeric...
Comment 22 GNOME Infrastructure Team 2018-05-22 14:36:39 UTC
-- 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.