Description: Desktop is Fedora 34 KDE spin, running Wayland. All patches are up to date. While I am editing an Impress presentation, if I select another application from the panel, then select Impress from the panel, it crashes the Impress session completely. Steps to Reproduce: 1.Start any desktop application such as KCalc 2.STart Impress and edit a presentation 3.Click on panel Kcalc to switch to that application 4.Click on panel Impress to switch back to presentation Actual Results: Impress crashes completely Expected Results: Impress should continue operating, allowing presentation to be edited. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.1.4.2 Build ID: 10(Build:2) CPU threads: 8; OS: Linux 5.12; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Does it also happen if you launch from the command line with SAL_USE_VCLPLUGIN=gtk3 libreoffice
If this was the stock fedora build, which it sounds like, was there an offer to report the bug from fedora itself ? If there was, and you approved it, there might have been a link to the fedora retrace shown (something like https://retrace.fedoraproject.org/faf/reports/206623/). A link like that would provide possibly useful backtrace info to give a hint as to the nature of the bug
(In reply to Buovjaga from comment #1) > Does it also happen if you launch from the command line with > > SAL_USE_VCLPLUGIN=gtk3 libreoffice No, it does not happen when starting with this option
I can reproduce on Debian testing in a Plasma Wayland session. It doesn't always happen when editing a presentation, but this way was reproducible for me: 0. Make sure to use a Plasma Wayland session (*might* be the same with SAL_USE_VCLPLUGIN=kf5 in a GNOME Wayland session, but I haven't tried) 1.Start any desktop application such as KCalc 2.Start Impress: ./instdir/program/soffice --impress 3. Select "Close" when the "Select a Template" dialog shows up 4. Click into the title box 5. type "ff" 6. switch to KCalc using either Alt+Tab or the entry in the task manager 7. Switch back to impress. Looks like some infinite recursion, s. attached backtrace gdbtrace.log (will attach afterwards). Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: c6695a4aabeaae99174b7658f2b813788ecff7f0 CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 173661 [details] Backtrace
(In reply to Caolán McNamara from comment #2) > If this was the stock fedora build, which it sounds like, was there an offer > to report the bug from fedora itself ? If there was, and you approved it, > there might have been a link to the fedora retrace shown (something like > https://retrace.fedoraproject.org/faf/reports/206623/). A link like that > would provide possibly useful backtrace info to give a hint as to the nature > of the bug The Bug Reporter did not pop up. However, when I open it manually, I do see the LibreOffice crash there. I tried first to create a core dump, after quite a while, it said it could not complete a core dump, and would I like to download huge files to produce a backtrace. I tried this, but after many hours, it still was incomplete, with no end it sight. Fortunately, I see that some other person from QA has been able to supply a backtrace. Is there anything else that you need from me at this time?
Created attachment 173688 [details] Single recursion of that backtrace Unfortunately there is no start in the long backtrace. I would happily blame this on QtWayland bugs, if you can't repo on X11, not that this would help the bug reporter ;-) While the loop is quite tight (just 21 frames), and the Qt5 code is even just 10 frames of it (the rest is generic VCL code, which is less likely to be wrong), I'm not sure where to resolve the chicken-egg problem... guess it's just too late today. OTOH after reading all the platform implementations of SalFrame::ToTop multiple times, I still don't understand, what these ToTop flags really mean, so that VCL Qt5 code is probably still buggy...
(In reply to Jan-Marek Glogowski from comment #7) > Created attachment 173688 [details] > Single recursion of that backtrace > > Unfortunately there is no start in the long backtrace. I would happily blame > this on QtWayland bugs, if you can't repo on X11, not that this would help > the bug reporter ;-) > > While the loop is quite tight (just 21 frames), and the Qt5 code is even > just 10 frames of it (the rest is generic VCL code, which is less likely to > be wrong), I'm not sure where to resolve the chicken-egg problem... guess > it's just too late today. > > OTOH after reading all the platform implementations of SalFrame::ToTop > multiple times, I still don't understand, what these ToTop flags really > mean, so that VCL Qt5 code is probably still buggy... So what are the next steps?
*** Bug 143521 has been marked as a duplicate of this bug. ***
Setting SAL_USE_VCLPLUGIN=gtk3 fixes the crash for me as well.
Running: SAL_USE_VCLPLUGIN=gtk3 libreoffice Worked for me too! I realize that we are making an assignment of SAL_USE_VCLPLUGIN to gtk3 in the environment prior to running libreoffice. Curious, can someone explain what SAL_USE_VCLPLUGIN actually is? Thanks!
(In reply to dennis.bayrock from comment #11) > I realize that we are making an assignment of SAL_USE_VCLPLUGIN to gtk3 in > the environment prior to running libreoffice. Curious, can someone explain > what SAL_USE_VCLPLUGIN actually is? It is forcing a certain VCL UI backend: https://docs.libreoffice.org/vcl.html
Still reproducible with version 7.2.0-2. SAL_USE_VCLPLUGIN=gtk3 solves problem but looking forward to actual fix :)
Still an issue with daily 7.3 (2021-09-24_02.59.08). As an alternative to using GTK3, setting libreoffice to run as an X11 app also works: XDG_SESSION_TYPE=x11 libreofficedev7.3
*** Bug 147040 has been marked as a duplicate of this bug. ***
I just closed my own duplicate. This happens in the same way on X11 for me (I somehow missed this bug. tdf#147040 actually has the bottom of the bt from the stack exhaustion. There is a preliminary patch in https://gerrit.libreoffice.org/c/core/+/132643. I need to update the bug id in the summary and maybe there is some better solution then the implemented workaround.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e81385277c091dabb1f6542a94229d7dcc77289b tdf#143135 Qt break recursive IM QueryCursorRect It will be available in 7.4.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.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/a174fe91987160c0d57099d0aaf49dcc8e036f5b tdf#143135 Qt break recursive IM QueryCursorRect It will be available in 7.3.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.
*** Bug 148752 has been marked as a duplicate of this bug. ***