Steps are the same as those described in bug 122042, except that this is on Wayland only now:
0. use a Wayland session (test was with Plasma on Debian testing)
1. Open writer with SAL_USE_VCLPLUGIN=kde5 soffice --writer
2. Type something
3. Select text
4. Close LO and select "Don't save"
Result: LibreOffice crashes.
The crash does not occur when
* using kde5 on X11 intead of Wayland
* switching to the gtk3 VCL plugin
This happens with the current daily build:
Build ID: f90e2a327f0d19225b5f54a10be6a3d12567a30a
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5;
TinderBox: Linux-rpm_deb-x86_64@86-TDF-dbg, Branch:master, Time: 2019-02-22_02:31:00
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Created attachment 149534 [details]
Created attachment 149555 [details]
On pc Debian x86-64 with master sources updated today + kde5 + wayland + enable-dbgutil, I could reproduce the crash.
Hope this bt + console logs may help.
With the pending change https://gerrit.libreoffice.org/#/c/73288 , patch set 11, the issue is no longer reproducible, so this will probably be fixed soon.
(In reply to Michael Weghorn from comment #3)
> With the pending change https://gerrit.libreoffice.org/#/c/73288 , patch set
> 11, the issue is no longer reproducible, so this will probably be fixed soon.
That change has been merged and the issue is gone, i.e. fixed with
Author: Jan-Marek Glogowski <firstname.lastname@example.org>
Date: Fri May 31 16:40:34 2019 +0000
tdf#122239 Qt5 implement lazy clipboard handling
This changes the Qt5Clipboard to a lazy loading one, which will
just deliver data on read requests. This fixes not only the
PRIMARY selection problems with Writer, but will generally speed
up C'n'P, inside LO, because the data has not to be copied or
transferred via QMimeData.
This is mainly done by implementing the "mirror" interface of the
Qt5Transferable, the Qt5MimeData using the retrieveData override.
To prevent clipboard loss on shutdown, this sets a deep copied
QMimeData of the current XTransferable, to make it persistent.
This code explicitly doesn't use any of the QMimeData convenience
functions and relies completely on LO's string handling, so we
won't mix in eventual Qt bugs; all bugs are ours...
Reviewed-by: Michael Weghorn <email@example.com>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>