Created attachment 189529 [details] Backtrace I built the current master from source and when I try to open a file (File - Open) and then switch to another folder (f.i. the Downloads folder) I get a crash. The problem seems to be Wayland-only. It does not happen on X11. Find attached the backtrace. System info Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d52feb11c7eab0adf82c1fb410adfd3127bf9497 CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+wayland) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded On the same machine using Wayland, the problem does not happen on: Version: 7.5.6.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: kf5 (cairo+wayland) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 4:7.5.6~rc2-0ubuntu0.23.04.1~lo1 Calc: threaded
Can't reproduce with my local debug build on Debian testing. Does this also happen with a downloaded daily master build or just with your local build? Does a 'make clean && make' change anything about this? (just 'make vcl.clean' instead of a full 'make clean' might be enough) Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 140fe3080da8dd6468a223cb7bb56d3734377b9c CPU threads: 12; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Dear Rafael Lima, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
(In reply to Michael Weghorn from comment #1) > Does this also happen with a downloaded daily master build or just with your > local build? Does a 'make clean && make' change anything about this? (just > 'make vcl.clean' instead of a full 'make clean' might be enough) Still repro. I have just downloaded the daily master, and used "make clean" before building it. Using File - Open results in crash. System info Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5bf7df62645f73ad69772f318ea3058dfd6fce12 CPU threads: 12; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+wayland) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded
(In reply to Rafael Lima from comment #3) > Using File - Open results in crash. I see occasional crashes with kf5 on Wayland now as well in that scenario (maybe after some library update), am wondering whether it's the same one. What seems to be the case in my setup, but it's not really reliably reproducible so far: * crash seems to happen more likely when running another LO build in parallel using `PARALLELISM=2 make` * happens sometimes when started with `./instdir/program/soffice --writer` * does NOT happen when started with `./instdir/program/soffice.bin --writer` (i.e. not using the `soffice` shell script, but the `soffice.bin` binary) How reproducible is the scenario for you? Does it crash when started via soffice.bin directly for you?
(In reply to Michael Weghorn from comment #4) > How reproducible is the scenario for you? Does it crash when started via > soffice.bin directly for you? So here's how this happens to me. Suppose I have just booted my machine... if I use: ./instdir/program/soffice --calc Then I get the crash. But if I then use soffice (no arguments) and open the Start Center, File - Open will work fine. Then I close the Start Center... if I now type the same command as initially: ./instdir/program/soffice --calc This will now work. No idea what's going on.
Created attachment 193346 [details] Relevant part of valgrind output
Created attachment 193347 [details] valgrind output showing similar issue for kate
After further analysis of the issue that I can reproduce (of which I am optimistic now that it is the same one), I think this is a Qt 5 or KF 5 bug, not a LibreOffice one. (In reply to Michael Weghorn from comment #4) > * does NOT happen when started with `./instdir/program/soffice.bin --writer` > (i.e. not using the `soffice` shell script, but the `soffice.bin` binary) Adding to that, the crash no longer happens for me when commenting (i.e. disabling) these 2 lines in `instdir/program/ooenv`: export MALLOC_CHECK_=2 export MALLOC_PERTURB_=153 , which indicates that there is some issue with memory management. Indeed, I can get the kate text editor to crash as well when started with these environment variables set: When opening the file dialog many times, it crashes at some point. attachment 193346 [details] shows the relevant valgrind output for LO with the kf5 VCL plugin on Wayland, which shows that there's a use-after-free. attachment 193347 [details] is a valgrind output for kate, showing the same issue (see lines 734ff). Therefore, I believe this is an issue in Qt or KF 5. -> Closing as NOTOURBUG. IIUC, this shouldn't be a problem for production use. While the memory issue is likely there, too, it doesn't seem to be a problem (not causing a crash) there, which is only triggered by those env variables. And these are only set in a development build, not a release build. @Rafael: Can you confirm the crash goes away for you as well when removing the 2 above-mentioned environment variables?
Given that Qt 5 is EOL and Plasma 6 has been released and this is a development-setup and Wayland-only issue, I'd abstain from forwarding to Qt upstream for now, unless this is also seen with kf6 (haven't seen it yet, but haven't used that that much either). Potentially the issue has been fixed upstream in the meanwhile.
(In reply to Michael Weghorn from comment #8) > @Rafael: Can you confirm the crash goes away for you as well when removing > the 2 above-mentioned environment variables? Yeah, I can confirm that it does not crash when I comment out these two environment variables. I didn't know this trick, thanks for pointing it out. This bug is actually a pain when building and testing LO on my second machine, where I run Wayland on Plasma 5.27... at least by commenting these lines, I can get around this issue. (In reply to Michael Weghorn from comment #9) > Given that Qt 5 is EOL and Plasma 6 has been released and this is a > development-setup and Wayland-only issue, I'd abstain from forwarding to Qt > upstream for now, unless this is also seen with kf6 (haven't seen it yet, > but haven't used that that much either). Potentially the issue has been > fixed upstream in the meanwhile. I agree that this is an upstream bug. But isn't Plasma 5.27 an LTS? So maybe it should be a good idea to report this issue upstream. I haven't built LO using Plasma 6 yet... so I can't tell whether the problem is there too. I have only tested the PPA version of LO under Plasma 6, but using the kf5 backend, since qt6 isn't being shipped yet in the PPA.
(In reply to Rafael Lima from comment #10) > Yeah, I can confirm that it does not crash when I comment out these two > environment variables. I didn't know this trick, thanks for pointing it out. Thanks for confirming. > This bug is actually a pain when building and testing LO on my second > machine, where I run Wayland on Plasma 5.27... at least by commenting these > lines, I can get around this issue. It is indeed. Other workarounds are using a different VCL plugin (e.g. SAL_USE_VCLPLUGIN=qt6 ) or forcing the use of the X11/xcb QT platform plugin instead of the native Wayland one ( QT_QPA_PLATFORM=xcb ). > I agree that this is an upstream bug. But isn't Plasma 5.27 an LTS? So maybe > it should be a good idea to report this issue upstream. Without analyzing further, I'd rather expect this to be a Qt issue. The KDE community still has a "patch collection" for Qt 5, but since the issue doesn't cause any user-visible issues in a "normal" setup, my assumption is that the most likely way to actually get a fix would be to analyze in more detail and either identify what commit fixed this for Qt 6 and suggest a backport, or come up with a fix oneself. I wouldn't feel able to create a proper bug report without spending more time. And while this is indeed annoying when using Wayland, my personal focus is more on qt6 than kf5/qt5 when it comes to non-critical things. > I haven't built LO using Plasma 6 yet... so I can't tell whether the problem > is there too. I have only tested the PPA version of LO under Plasma 6, but > using the kf5 backend, since qt6 isn't being shipped yet in the PPA. Do you see the issue with kf5 with that PPA? (My initial assumption would be no, as I'd expect that to be a release build, where the environment variables causing the crash shouldn't be set.)