Description of problem:
When using the GTK3 VCL plug-in, basic interactions with the GUI cause immediate crashes. Note this is reproducible (for me anyway) only on i686, not on x86_64. I don't know if it's an issue with 64-bit assumptions (which would then potentially impact ARMv7 as well), or just something architecture-specific, or I just happen to be unlucky with one laptop and not the other.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open a document in Writer.
2. Resize the document view to something different.
3. Open the find bar.
4. Type in a search string that is known to exist in the document and press the down arrow to search forward.
5. Immediate segfault.
(I'm not sure why this particular series of steps works, but I can reproduce it every time doing exactly that.)
Immediate crash, which invokes the document recovery process.
UI should work normally.
(An additional weirdness is that after document recovery is completed, when the application reopens, it gets stuck in a small window that will not resize, and the menu entries in the Gnome activity bar at the top are greyed out. Totally unrelated, but also annoying.)
I forgot to add, I cannot reproduce this crash if I do not use the GTK3 VCL plug-in. If I use the GTK2 or X11 plug-ins, things work fine. So the workaround is to use one of those others.
Created attachment 1174222 [details]
GDB backtrace of the crash
GDB "bt full" backtrace results from the crash.
doesn't happen for me under wayland or X yet.
cause the ClipboardClear is called on an apparently broken VclGtkClipboard I assume this is a use after free and its apparently triggered by the gtk_clipboard_clear call in ::setContents
Due to bug 1350478 I had to rework the c-n-p again, and it so happens that there isn't that explicit gtk_clipboard_clear call in the rework, which may fix this, or move the problem around to somewhere else
lets check in the next update once it gets out of the arm build
I can still reproduce the crash with 220.127.116.11-4. (I can also trigger crashes at random by doing other things, e.g. once it crashed while the file selection window was opening after I clicked on "save as", but my original method reproduces consistently.) I'll attach a revised backtrace.
Created attachment 1174735 [details]
GDB backtrace for 18.104.22.168-4.
I just reproduced this on x86_64, so it's not an architecture-specific issue after all. (I didn't hit this before following the same steps, but now I do.)
I saw a fix went in for another clipboard-related issue (bug 1352965), so I re-tested with 22.214.171.124-5. It still segfaults, and the backtrace is basically identical.
(Separately, I'm also seeing random crashes in Calc that occur after it's been left idle for some time, also occurring only with the GTK3 VCL. I don't have a usable backtrace for these yet, they only occur intermittently.)
Is this under wayland or X. I can't get this to happen for me under either, but I know there's a bug with the primary selection under wayland in gtk3 itself
It's under X.
Where I said "resize the document view to something different" in the reproduction steps, I can only reproduce this when I click on the view percentage in the bottom right corner of the screen and then interact with the resulting menu that way. If I use View->Zoom, it doesn't happen, or so it seems. It also seems to require a large document to trigger the problem. And while I've encountered it on x86_64, it's really only consistently reproducible on i686 as far as I've found. I'll attach a sample document I can reproduce this with.
Created attachment 1178531 [details]
Sample large document I can reproduce this with
hmm, while I can't reproduce this I have a feeling that we might be deleting our clipboard implementation through reference counting hitting 0 under some circumstances.
I'll generate some builds to test the theory
That seems to have fixed it. I can't duplicate the crash anymore with any of the actions and documents in question. Thanks!
libreoffice-126.96.36.199-6.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-cb25df449f