Bug 121293 - kde5: Presentation Minimizer wizard does not terminate
Summary: kde5: Presentation Minimizer wizard does not terminate
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected)
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: target:6.3.0
Depends on:
Blocks: KDE, KF5
  Show dependency treegraph
Reported: 2018-11-08 22:56 UTC by Michael Weghorn
Modified: 2019-11-15 00:31 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

GDB backtrace when dialog "hangs" (15.59 KB, text/plain)
2019-01-03 15:21 UTC, Michael Weghorn
Updated GDB log when LO "hangs" (22.07 KB, text/plain)
2019-03-15 14:06 UTC, Michael Weghorn

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Weghorn 2018-11-08 22:56:31 UTC
Build ID: 2c614b4b2537997aece7ba0aa7ecd38e55fcffaa
CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: kde5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

Steps to Reproduce:
1) Open some .odp file
2) make sure another .odp file to overwrite exists on disk
  (e.g. create one by using "File" -> "Save Copy"; necessary because of bug 121276).
3) Tools -> Minimize Presentation
4) Go through Presentation Minimizer Wizard with default settings -> "Finish"
5) Select an existing .odp file (s. step 2) to overwrite and click "Save" -> "Overwrite"

Result: The progress bar continues, but the dialog remains at "Optimizing images..." rather than closing. The whole LibreOffice and most of the desktop appears "frozen", and the LibreOffice process needs to be terminated from a terminal window.

Expected result: No freeze should occur. A dialog indicating that minimizing the presentation is finished should be shown.


* This happens for me most of the times I try, but very seldomly, it works correctly instead.
* This is not reproducible when using e.g. the gtk3 VCL plugin.
Comment 1 Vera Blagoveschenskaya 2018-11-09 07:16:57 UTC
Well, I can reproduce it with score 1:10

Build ID: dbe94dd3b64e74f661ea7193d8e06ac91f1dd7b0
CPU threads: 1; OS: Linux 4.14; UI render: default; VCL: kde5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-07_16:15:05
Locale: ru-RU (ru_RU.UTF-8); Calc: threaded
Comment 2 Michael Weghorn 2018-11-09 14:54:18 UTC
According to bug 117466, a crash appears for the kde4 VCL plugin, which may or may not be related.
Comment 3 Xisco Faulí 2018-11-12 14:35:14 UTC
Moving to NEW
Comment 4 Michael Weghorn 2019-01-03 15:21:58 UTC
Created attachment 147971 [details]
GDB backtrace when dialog "hangs"
Comment 5 Michael Weghorn 2019-01-03 15:23:09 UTC
(In reply to Michael Weghorn from comment #4)
> Created attachment 147971 [details]
> GDB backtrace when dialog "hangs"
The backtrace looks quite different from the KDE4 one in bug 117466, so that seems to be another issue.
Comment 6 Katarina Behrens (Inactive) 2019-03-14 09:56:29 UTC
The same story as in bug 121516: please retest, this looks very much like threading/locking issue and thus it might be fixed by one of the threading patches that went to master last week
Comment 7 Xisco Faulí 2019-03-14 10:02:57 UTC
Yep, it's fixed in

Build ID: 17b25fd3df237a64d6a28fbc57b869e080963193
CPU threads: 2; OS: Linux 4.15; UI render: default; VCL: kde5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time:
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

as well
Comment 8 Michael Weghorn 2019-03-15 14:05:54 UTC
Unfortunately still reproducible for me with today's master build:

Build ID: c8bad5e896801e6775fd80ea246893a77f534d60
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded
Comment 9 Michael Weghorn 2019-03-15 14:06:52 UTC
Created attachment 149997 [details]
Updated GDB log when LO "hangs"
Comment 10 Michael Weghorn 2019-03-15 16:35:31 UTC
The backtrace shows some X11-specific methods/functions ('xcb_wait_for_reply', 'QXcbConnection::sync()',...).
Actually, I couldn't reproduce on Wayland when trying multiple times now  with the same build of LibreOffice.
Thus, this may be X11-specific (though I cannot say for sure since it also doesn't happen in 100 % of the cases on X11 for me).

System is Debian testing with Qt packages at version 5.11.3+dfsg-5.
Comment 11 Michael Weghorn 2019-06-05 12:36:14 UTC
This is now fixed with the following commit

commit e770bacc85a0eec96de77068d61b03f374b3cdec
Author: Jan-Marek Glogowski <glogow@fbihome.de>
Date:   Sun Jun 2 21:01:33 2019 +0000

    Qt5 workaround modal change after show bug
    The presentation minimizer dialog calls setVisible before execute.
    This results in the dialog being shown before setting the modality
    in execute. And this triggers a bug in the Qt / Xcb stack (gtk is
    fine because it directly uses XSendEvent to change the state).
    The result is an unmapped, modal dialog window: it's invisible and
    blocks the GUI. Qt believes it's show; isVisible() returns true.
    And my ~/.xsession-errors shows a "qt.qpa.xcb: QXcbConnection: XCB
    error: 3 (BadWindow) ... major code: 18 (ChangeProperty)" with an
    invalid resource id, according to 'xwininfo -tree -root'.
    You can find the window resource of the minimizer by its name in
    the full root tree and its unmapped state with 'xwininfo -id'.
    I originally thought of a Scheduler bug so enabled debug output
    for it. This is already responsible for a delay long enough to
    prevent the bug often. Same for doing an additional hide() and
    show() sequence. In the end I went with a fixed delay, but that
    is just a guess. In theory we could check the mapped state via
    Xlib in Qt's show event and manually map it using XMapWindow and
    the winId...
    I also noted that the minimizer leaks, as there are multiple new
    presenter resources after each show and hide...
    Change-Id: I2060918aa9c63d385ebb2ffee9e7a3e4196ea766
    Reviewed-on: https://gerrit.libreoffice.org/73462
    Tested-by: Jenkins
    Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
    Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>