The "Preview Dialog" tool is causing the Basic IDE to freeze when using kf5. Does not happen with gtk3 or gen. Steps to reproduce: 1) Open the Base Dialog Editor for any dialog (Tools - Macros - Organize Dialogs). If you don't have any dialogs of your own, choose one of the built-in dialogs, such as Application Dialogs - Euro - DlgConvert, and click Edit 2) Click the Preview Dialog tool. It's located in the toolbar at the bottom of the window (3rd button). Also accessible via the Dialog - Preview Dialog menu. 3) The Basic IDE freezes instantly. However other opened LO applications continue working. When running from the terminal, I get the following error message when the "Preview Dialog" button is clicked. qt.qpa.xcb: internal error: void QXcbWindow::setNetWmStateOnUnmappedWindow() called on mapped window Most of the times it freezes the first time I try to execute the Preview Dialog... but there was an occasion where the first attempt worked but froze in the second attempt. System info Version: 7.4.3.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.4.3-0ubuntu0.22.10.1 Calc: threaded
Also repro with latest master Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8336c61ba059551cb74df5ec53d2b45a3cf41814 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded
Couldn't reproduce the bug with Version: 7.4.4.2 / LibreOffice Community Build ID: 85569322deea74ec9134968a29af2df5663baa21 CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Also tested with Version: 7.5.0.1 (X86_64) / LibreOffice Community Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded on OpenSUSE 15.3 64bit rpm Linux
Can't reproduce on Debian testing with either current master Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d2318503d559c3797965da777627e4ee45143043 CPU threads: 12; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_GB.UTF-8); UI: en-US Calc: threaded or Debian-provided Version: 7.4.4.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 12; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-GB Debian package version: 1:7.4.4~rc2-2 Calc: threaded
Not reproduced Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f0ff4243d45b11f372a2ed824fbb8806de9cb595 CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 17 March 2023
I don't know what's going on, but the problem persists on my machine (actually on my PC and my laptop), both with 7.5.1 and 7.6 master. As soon as I click the Preview Dialog button, LO freezes.
This may be a Qt bug? https://bugreports.qt.io/browse/QTBUG-82059 But I'm not expert enough in Qt to confirm whether this is our bug or not.
(In reply to Rafael Lima from comment #6) > This may be a Qt bug? > > https://bugreports.qt.io/browse/QTBUG-82059 > > But I'm not expert enough in Qt to confirm whether this is our bug or not. This looks plausible to me, might be the same issue. (It's still interesting this happens for you, but not everybody). Can you attach a backtrace? (In reply to Rafael Lima from comment #0) > When running from the terminal, I get the following error message when the > "Preview Dialog" button is clicked. > > qt.qpa.xcb: internal error: void > QXcbWindow::setNetWmStateOnUnmappedWindow() called on mapped window That message is from Qt's xcb/X11 platform code. If you have the chance to test this: Does it freeze in a Wayland session (i.e. with "VCL: kf5 (cairo+wayland)" as well, or just on X11? Just to be sure: Does this also happen with a fresh LO profile?
Created attachment 186055 [details] Backtrace Here's the backtrace while reproducing the bug. It was created using LO 7.6 built from master using a clear user profile. This was created using an X11 session (Kubuntu 22.10). I'll try Wayland and report back how it went.
On Wayland the preview works fine.
(In reply to Rafael Lima from comment #8) > Created attachment 186055 [details] > Backtrace > > Here's the backtrace while reproducing the bug. It was created using LO 7.6 > built from master using a clear user profile. Thanks. Could you please install the relevant Qt debug symbols (probably in a package called libqt5core5a-dbgsym or so on Ubuntu) and create + attach another backtrace that hopefully shows more info on where in the Qt library the involved threads are? The GDB log says this at the beginning, so maybe using debuginfod instead of the debug packages might also work if you confirm that in an interactive GDB session (answer the question with "y" instead of the default "n"): > This GDB supports auto-downloading debuginfo from the following URLs: > https://debuginfod.ubuntu.com > Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal] What I'd try is this: * install debug symbols for /lib/x86_64-linux-gnu/libQt5Core.so.5 (unless this "just works" with debuginfod as alternative) * start LO with GDB from command line: `gdb --args ./instdir/program/soffice.bin --writer` (type "r" to start running the program once the GDB prompt occurs) * reproduce the freeze * in the terminal where GDB runs: press Ctrl+C to pause the execution, then type "thread apply all bt" in the GDB prompt to generate the backtrace for all threads (and attach the result here)
Created attachment 186057 [details] New Backtrace Here's the updated backtrace. I installed the debug symbols and used gdb following the steps provided. Thanks for the detailed instructions.
(In reply to Rafael Lima from comment #11) > Here's the updated backtrace. I installed the debug symbols and used gdb > following the steps provided. Thanks. Unfortunately, it's not really clear for me from the backtrace where the problem is. The more relevant backtrace might be how the Qt code that emits the warning is reached. Anyway, I have on idea where the problem *might* be caused. This here looks like it may be related: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=3714e51436eebb64873c58dc36cf89ef8f139f09 And we had a similar workaround before, added in commit e770bacc85a0eec96de77068d61b03f374b3cdec Date: Sun Jun 2 21:01:33 2019 +0000 Qt5 workaround modal change after show bug but then dropped again in commit 2dc6bdd1d5789ace0500cad90f5d2eb930888bb9 Date: Wed Jun 5 17:39:45 2019 +0000 tdf#125692 SalObject always holds a SystemChildWindow Does it still hang if you make `QtFrame::SetModal` do nothing? diff --git a/vcl/qt5/QtFrame.cxx b/vcl/qt5/QtFrame.cxx index 5517584b72d7..5092f55c6eb3 100644 --- a/vcl/qt5/QtFrame.cxx +++ b/vcl/qt5/QtFrame.cxx @@ -609,6 +609,9 @@ SalFrame* QtFrame::GetParent() const { return m_pParent; } void QtFrame::SetModal(bool bModal) { + if (true) + return; + if (!isWindow() || asChild()->isModal() == bModal) return; And if that makes the problem go away: Does the freeze also disappear if you undo that change and add a sleep instead, like this: diff --git a/vcl/qt5/QtFrame.cxx b/vcl/qt5/QtFrame.cxx index 5517584b72d7..12af2103e965 100644 --- a/vcl/qt5/QtFrame.cxx +++ b/vcl/qt5/QtFrame.cxx @@ -621,7 +621,10 @@ void QtFrame::SetModal(bool bModal) // modality change is only effective if the window is hidden if (bWasVisible) + { + QThread::msleep(500); pChild->hide(); + } pChild->setWindowModality(bModal ? Qt::WindowModal : Qt::NonModal);
(In reply to Michael Weghorn from comment #12) > And if that makes the problem go away: Does the freeze also disappear if you > undo that change and add a sleep instead, like this: > > diff --git a/vcl/qt5/QtFrame.cxx b/vcl/qt5/QtFrame.cxx > index 5517584b72d7..12af2103e965 100644 > --- a/vcl/qt5/QtFrame.cxx > +++ b/vcl/qt5/QtFrame.cxx > @@ -621,7 +621,10 @@ void QtFrame::SetModal(bool bModal) > > // modality change is only effective if the window is hidden > if (bWasVisible) > + { > + QThread::msleep(500); > pChild->hide(); > + } > > pChild->setWindowModality(bModal ? Qt::WindowModal : Qt::NonModal); Or maybe the `QThread::msleep(500);` would have to be added after the `pChild->hide();`, at least that's what the original workaround in LO did.
(In reply to Michael Weghorn from comment #12) > Does it still hang if you make `QtFrame::SetModal` do nothing? > > diff --git a/vcl/qt5/QtFrame.cxx b/vcl/qt5/QtFrame.cxx > void QtFrame::SetModal(bool bModal) > { > + if (true) > + return; > + With the change above, the preview is shown as expected. > And if that makes the problem go away: Does the freeze also disappear if you > undo that change and add a sleep instead, like this: > // modality change is only effective if the window is hidden > if (bWasVisible) > + { > + QThread::msleep(500); > pChild->hide(); > + } Removing the previous change and then adding the sleep makes the problem go away as well. > Or maybe the `QThread::msleep(500);` would have to be added after the > `pChild->hide();`, at least that's what the original workaround in LO did. Using "QThread::msleep(500)" before and after "pChild->hide();" has the same effect. In both cases the preview is shown after 0.5 seconds. FWIW I tried with 100ms and it also worked... the wait is barely noticeable. If we choose to reinstate this hack, may we could try with only 100ms.
Thanks for your tests. > FWIW I tried with 100ms and it also worked... the wait is barely noticeable. > If we choose to reinstate this hack, may we could try with only 100ms. Sounds good, I've submitted a change to do this: https://gerrit.libreoffice.org/c/core/+/149912 (The original sleep was also just 250 ms, I increased that for the initial test just to be sure.)
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/574a5519e23e8ed50c54fb27587afb1b5b5c13c5 tdf#152979 qt: Re-add workaround for X11 modality change w/ hide/show It will be available in 7.6.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.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/dacdb5a424601e9ee33f57cceb79f3835530654f tdf#152979 qt: Re-add workaround for X11 modality change w/ hide/show It will be available in 7.5.3. 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.