Summary: | kde5: Presentation Minimizer wizard does not terminate | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Michael Weghorn <m.weghorn> |
Component: | Impress | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | m.weghorn, thb, vercha, xiscofauli |
Priority: | medium | ||
Version: | 6.2.0.0.alpha1+ | ||
Hardware: | All | ||
OS: | Linux (All) | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=121276 https://bugs.documentfoundation.org/show_bug.cgi?id=117466 https://bugs.documentfoundation.org/show_bug.cgi?id=123985 https://bugs.documentfoundation.org/show_bug.cgi?id=128710 |
||
Whiteboard: | target:6.3.0 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 102495 | ||
Attachments: |
GDB backtrace when dialog "hangs"
Updated GDB log when LO "hangs" |
Description
Michael Weghorn
2018-11-08 22:56:31 UTC
Well, I can reproduce it with score 1:10 Version: 6.2.0.0.alpha1+ 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 According to bug 117466, a crash appears for the kde4 VCL plugin, which may or may not be related. Moving to NEW Created attachment 147971 [details]
GDB backtrace when dialog "hangs"
(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. 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 Yep, it's fixed in Version: 6.3.0.0.alpha0+ 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: 2019-03-13_20:42:25 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded as well Unfortunately still reproducible for me with today's master build: Version: 6.3.0.0.alpha0+ 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 Created attachment 149997 [details]
Updated GDB log when LO "hangs"
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. 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> |