[Libreoffice-bugs] [Bug 131533] New: Qt5 crash when closing LO with a 2nd consecutive selection

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Tue Mar 24 14:14:40 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=131533

            Bug ID: 131533
           Summary: Qt5 crash when closing LO with a 2nd consecutive
                    selection
           Product: LibreOffice
           Version: 7.0.0.0.alpha0+ Master
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: graphics stack
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: glogow at fbihome.de

I couldn't really come up with a good summary, as the reproducer is a bit
complex.

While debugging bug 125809, I found the following crash, easiest reproducible
with Draw.

1. Start Draw from a terminal
2. Open galleries sidebar
3. Drag anything from the Sidebar into the document. The new item will be and
has to stay selected!
4. Drag anything from the Sidebar into the document again. The new item will be
and has to stay selected!
  - on the terminal you'll see: "QXcbClipboard::setMimeData: Cannot set X11
selection owner"
  - at this point the Qt5 internal selection state doesn't match the LO state
anymore.
5. Close and discard the document without removing the selection (Ctrl + w)
6. Close the start center (Ctrl + w).
7. Crash when QApplication tries to release the LO selection on shutdown.

LO normally release the clipboard when closing a module (Draw). This doesn't
happen correctly now.

The simple workaround is to select something else before closing the document,
so the clipboard state is corrected.

Clearing the clipboard somehow interferes with the D'n'D action when there is
already a selection. I tried to understand, why the setMimeData() call after
the clear() fails, but came up with nothing. I guess the someone else
(clipboard manager?) claims the clipboard after LO gives it up with the
clear(). The current fix is to queue the clear and ignore it, if it's directly
followed by a claiming setContent.

This initially "nice" Qt5Clipboard code already feels like it needs some
refactoring to make it easier to follow...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200324/91e0c440/attachment.htm>


More information about the Libreoffice-bugs mailing list