Description: SAL_USE_VCLPLUGIN=gtk4 causes libreoffice to crash when it opens a presentation. This happens using linux, with KDE plasma 6 and wayland. Impress does not crash until the presentation is opened. It does not crash with the gtk3 or kf6 VCLs. Steps to Reproduce: 1. Launch SAL_USE_VCLPLUGIN=gtk4 libreoffce 2. open a presentation Actual Results: Libreoffice shows an error dialog and closes Expected Results: No crash Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk4 Locale: it-IT (en_US.UTF-8); UI: en-US 24.2.3-1 Calc: threaded
This is different from https://bugs.documentfoundation.org/show_bug.cgi?id=157452 because the crash is now opening the presentation, not during the display of a dialog.
idem as tdf#157452 "Before trying to get a backtrace, please try a recent LO version (7.6.7 or brand new 24.2.4)"
Created attachment 196363 [details] GDB trace of opening Draw with gtk4 I took this trace before I found this report. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: edc20f4d34d102b385ece53a60abad0047661661 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: gtk4 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded
On pc Debian x86-64 with master sources updated today, I got no crash but noticed these on console: (soffice:28621): GLib-GObject-CRITICAL **: 10:45:43.034: ../../../gobject/gsignal.c:2532: signal 'size-allocate' is invalid for instance '0x563570966a70' of type 'GtkNotebook' (soffice:28621): GLib-GObject-CRITICAL **: 10:45:45.162: invalid cast from 'GMenu' to 'GtkPopoverMenu' (soffice:28621): Gtk-CRITICAL **: 10:45:45.162: gtk_popover_menu_get_menu_model: assertion 'GTK_IS_POPOVER_MENU (popover)' failed warn:sfx:28621:28621:sfx2/source/sidebar/TabBar.cxx:327: Skipping update of sidebar menus to avoid crash due to gtk4 menu brokenness. Could not find platform independent libraries <prefix> Could not find platform dependent libraries <exec_prefix> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>] warn:sfx:28621:28621:sfx2/source/sidebar/TabBar.cxx:327: Skipping update of sidebar menus to avoid crash due to gtk4 menu brokenness. (soffice:28621): Gtk-WARNING **: 10:45:46.582: Cannot connect attribute 'surface' for cell renderer class 'GtkCellRendererPixbuf' since attribute does not exist warn:sfx:28621:28621:sfx2/source/sidebar/TabBar.cxx:327: Skipping update of sidebar menus to avoid crash due to gtk4 menu brokenness. warn:sfx:28621:28621:sfx2/source/sidebar/TabBar.cxx:327: Skipping update of sidebar menus to avoid crash due to gtk4 menu brokenness. Michael: I don't know if you're working on gtk4 but I noticed accessibility part in Buovjaga's bt, thought you might be interested.
(In reply to Julien Nabet from comment #4) > Michael: I don't know if you're working on gtk4 ... Not actively. (I started working on gtk4 a11y, but this is currently paused, mainly due to lack of upstream GTK 4 API, see https://lists.freedesktop.org/archives/libreoffice/2024-March/091665.html ). > ... but I noticed accessibility > part in Buovjaga's bt, thought you might be interested. That backtrace shows an assert in a11y code, which is only relevant in debug builds. (I've occasionally seen that with gtk4 as well when actually working on a11y, i.e. when Accerciser or Orca were running, but not without them active. The underlying issue is somewhere else and would need further investigation.) In any case, that shouldn't be any problem with release builds. @Reporter: Does this still happen with a current development version of LO? If so, can you please get + attach a backtrace? @Buovjaga: Is that backtrace for the specific scenario/steps described in the initial description? Do you have any AT running? Does commenting the assert make things work as expected? Note that the gtk4 VCL plugin is currently experimental, and therefore it's not used anywhere by default. -> Reducing severity to "normal" again for now.
(In reply to Michael Weghorn from comment #5) > @Buovjaga: Is that backtrace for the specific scenario/steps described in > the initial description? Do you have any AT running? Does commenting the > assert make things work as expected? Not exactly. As mentioned, it is for opening Draw. It is reproduced also with a symbols build. I don't have any AT running. I can try the assert change later. > Note that the gtk4 VCL plugin is currently experimental, and therefore it's > not used anywhere by default. -> Reducing severity to "normal" again for now. Severity is not priority. Severity is the effect, priority is the subjective importance.
(In reply to Buovjaga from comment #6) > Not exactly. As mentioned, it is for opening Draw. That makes me wonder: (In reply to Callegar from comment #0) > 2. open a presentation @Callegar: Does "open a presentation" just mean starting Impress (e.g. via "File" -> "New" -> "Presentation") or starting the slide show (e.g. using F5) after that? (For some reason, I was assuming the latter, in which case the Draw issue might be something completely different.) Can you please also attach a screenshot of the error dialog you're mentioning? (In reply to Buovjaga from comment #6) > Severity is not priority. Severity is the effect, priority is the subjective > importance. OK, please feel to adjust the fields again as makes sense. As a side note: In case of tracking gtk4 issues more systematically, a corresponding meta bug might also make sense. (I also ran into e.g. menu-related issues, but didn't file bugs yet as I didn't expect gtk4 to be production-ready at this point.)
(In reply to Michael Weghorn from comment #7) > @Callegar: Does "open a presentation" just mean starting Impress (e.g. via > "File" -> "New" -> "Presentation") or starting the slide show (e.g. using > F5) after that? FWIW, both of these work just fine for me on Debian testing (in a KDE Dev Wayland session) with a local LO master debug build. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ca92667f876505777f95d4019d329afa14d55a26 CPU threads: 32; OS: Linux 6.10; UI render: default; VCL: gtk4 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded
Well, it crashes when trying to open *any* application.
It also crashes when quitting, going into a recovery loop.
(In reply to Buovjaga from comment #6) > I can try the assert change later. If that helps, turning the assert into a SAL_WARN could be a workaround for now.
(In reply to Michael Weghorn from comment #11) > (In reply to Buovjaga from comment #6) > > I can try the assert change later. > > If that helps, turning the assert into a SAL_WARN could be a workaround for > now. Doesn't help in a symbols build, but I guess the assert would not have been hit anyway. So //assert(nThisChildIndex != -1); in vcl/unx/gtk4/a11y.cxx if I understood correctly.
(In reply to Buovjaga from comment #12) > //assert(nThisChildIndex != -1); > > in vcl/unx/gtk4/a11y.cxx if I understood correctly. Yes, exactly. Can you please attach the backtrace you get with that in place?
Created attachment 196383 [details] GDB trace with symbols build with assert commented out (In reply to Michael Weghorn from comment #13) > (In reply to Buovjaga from comment #12) > > //assert(nThisChildIndex != -1); > > > > in vcl/unx/gtk4/a11y.cxx if I understood correctly. > > Yes, exactly. Can you please attach the backtrace you get with that in place? Here.
(In reply to Buovjaga from comment #14) > Here. Thanks. Does https://gerrit.libreoffice.org/c/core/+/173216 fix the crash - or at least result in a different backtrace?
(In reply to Michael Weghorn from comment #15) > (In reply to Buovjaga from comment #14) > > Here. > > Thanks. Does https://gerrit.libreoffice.org/c/core/+/173216 fix the crash - > or at least result in a different backtrace? Congrats for solving everything :) No crash upon launch of apps or quitting!
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e94a35275670e0e3775c1bba305115d9941751f1 tdf#161256 gtk4 a11y: Don't crash on missing context or invalid child index It will be available in 25.2.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.
(In reply to Buovjaga from comment #16) > Congrats for solving everything :) No crash upon launch of apps or quitting! Great, thanks for testing. :) -> Closing as fixed. @Callegar: If you still see crashes, please create a new bug report with more details and a backtrace from a current daily build.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/1508a686875868b20c9ebac09ad817e40defe62e tdf#161256 gtk4 a11y: Don't crash on missing context or invalid child index It will be available in 24.8.2. 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.