Bug 131533 - Qt5 crash when closing LO with a 2nd consecutive selection
Summary: Qt5 crash when closing LO with a 2nd consecutive selection
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0 target:6.4.4
Keywords:
Depends on:
Blocks: KDE, KF5
  Show dependency treegraph
 
Reported: 2020-03-24 14:14 UTC by Jan-Marek Glogowski
Modified: 2020-03-31 00:58 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan-Marek Glogowski 2020-03-24 14:14:40 UTC
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...
Comment 1 Michael Weghorn 2020-03-25 07:52:07 UTC
I can reproduce with master as of commit 7de7512718ac192fcad441d5500d056316f72d72.
Comment 2 Jan-Marek Glogowski 2020-03-25 16:47:43 UTC
There is some additional discussion in the proposed patch: https://gerrit.libreoffice.org/c/core/+/90990
Comment 3 Commit Notification 2020-03-25 21:16:47 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/313081c0703c66918e95640c74cd57312a1e8bba

tdf#131533 Qt5 defer dropping clipboard ownership

It will be available in 7.0.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 4 Commit Notification 2020-03-31 00:58:11 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/dbe45b7930dc027cf6d143dbb34390c469808e10

tdf#131533 Qt5 defer dropping clipboard ownership

It will be available in 6.4.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.