Hi, I am experiencing critical graphics issues with LO on linux, namely i) either very slow GUI responsiveness ii) or frequent crashes of LO inducing crashes of the complete user session These two types of issues can be 'toggled' depending on the graphics driver configuration. First, some system info: LO Version: 5.3.6.1, Build-ID: 686f202eff87ef707079aeb7f485847613344eb7 (vanilla version from the LO site) OpenSuSE Leap 42.3, kernel 4.4.87-25-default (and previous 4.4.x) KDE Plasma 5.8.7 Lenovo T460s Core i7 laptop with onboard graphics VGA compatible controller: Intel Corporation Skylake Integrated Graphics (rev 07), HD Graphics 520 The issues do not depend on having a vanilla LO version or the LO version from the distribution's vendor i.e. OpenSuSE. These issues also do not depend on 'per-user-configurations', i.e. they occur for any user, even freshly created ones. There are no known issues on this machine for other graphics intensive applications (eg. blender, mayavi, inkscape, gimp, ...) For this intel graphics card two driver options exist: a) kernel builtin modesetting driver b) intel's own xf86 video driver for X For driver a), i.e. the kernel's builtin modesetting driver I am getting issue # i), i.e. the responsiveness of LO's GUI is only very poor - up to the point where a productive workflow can not be sustained. By that I mean for example: - in LO Impress, zooming slides of an empty fresh presentation takes ~1 sec. per each zoom step - deleting entries from a slide in LO Impress takes about ~1 sec. per deletion - relocating objects on a slide within LO Impress takes ~1 sec. per relocation - resizing the complete LO window on the desktop is sluggish, takes anything between 1..3 secs., producing artifacts within the window while resizing For driver option b), i.e. intel xf86, enabling DRI3, sna acceleration and tear freeness, LO's GUI is acceptably responsive however then, LO can be crashed very hard, involving the complete user's desktop session. These crashes are not fully reproducible, however, for certain actions in LO they occur very frequently. By that I mean ~ every 1 out of 3 or so of these particular actions. One such line of action is - create a new LO Impress document - create a standard filled shape, say a filled ellipse - apply transparency to the filled shape - grab the shape and relocate it several times on the slide If the crash occurs after the last step it involves - LO itself - KDE's session manager ksmserver at best the user is returned to the login screen of the KDE, sometimes also just to the boot console. Typical suggestions on the net, related to kernel options for the x686 driver, like i915.enable_rc6=1 i915.enable_fbc=1 i915.semaphores=1 have been attempted with no change For none of the two driver types OpenGL can be activated within LO. It leads to complete corruption of LO's GUI. For additional information I've attached: - typical backtrace of LO's coredump (no symbol table available at LO download site?) - typical backtrace of ksmserver's coredump (symbol table only installed for ksmserver. If others needed, pls let me know) - photo taken from the machine's screen at 'systemctl isolate multi-user.target' after the crash Any help would be most welcome I will be happy to provide additional information. wbwb
Created attachment 136507 [details] LO backtrace
Created attachment 136508 [details] ksmserver backtrace
Created attachment 136509 [details] screen photo at 'systemctl isolate multi-user.target'
The same happens to me. KDE Session crashes with Libreoffice 6.0.2.1 The important part is: - only Libreoffice crashes KDE, no other program does - I am in LO, when it crashes in no other program - other programs run too - this is a recurring problem, starting with LO 5.X and continuing wit LO 6.X in every iteration Additional information: - Laptop with touch-screen and pen, maybe a driver issue (but it *only* manifests with one program: Libreoffice) - selecting something may be a trigger (it happens most often then, but not only) I am going to switch to Ubuntu 18.04 and Gnome when it comes out. I have no clue how to debug it or do something about it. It happens so often that working with LO/KDE becomes cumbersome. Crash Report in 6.0.2.1 seems to be working again: https://crashreport.libreoffice.org/stats/crash_details/3905c844-d54d-4f84-80cb-2b6c1e1f36c6#allthreads
try to update your kernel, it can help https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/42.3/ Update of Kernel Graphics Stack # On openSUSE Leap 42.3, the upgrade of the graphics stack up to 4.9.x kernel code is provided via the package drm-kmp-default instead of backporting many patches into the kernel itself. Usually, this package is installed automatically during the OS installation when a corresponding graphics device is found on your machine. The KMP gives users also another benefit: You can roll back to the 4.4.x kernel code by uninstalling this package. If you face critical issues, like a hung GPU, try to uninstall the package as shown below, then reboot and retest: zypper rm drm-kmp-default
Wow, quite a number of months have passed until this may actually be some activity related to this bug(?) Are you sure its the same bug? Are you using the same linux distro and version of LO? Did you diff the backtraces attached to this bug and is it comparable to your's? Is the onscreen stream of error msgs the same for you as the one attached to this bug? LO can crash because of just so many different things .... The overwhelming response during the last 6 months to this severe crash shows just once again, as so many times, that the documentfoundation simply dgaf if LO is working on linux or not. I mean, this bug kills a running linux systems completely - cmon - that's just unbelievable - way 'better' than anything to expect from msdooze-office. But documentfoundation is unable to fix it. Here's my fix: I'm using Version 4.2.8.2. It runs just fine. Anyway, the main 'improvements' by the documentfoundation to LO ever since they overtook from OpenOffice is to overlay each new version by the next level of even more buggy GUI. Why bother with that. The core functionality has never improved significantly since the very early versions. Just stay with them - forget about new versions- and do your work.
I have not compared the backtraces as I don't know how. But I have had a look at some of my crash reports which get automatically sent to Libreoffice. They look different to my naked eye each time. But honestly, I haven't the time and I have actually given up hope of this bug ever being resolved and use LO 5.X which comes with KDE Neon and I will switch to Ubuntu/Gnome during summer. Just to be complete, here are some URLs that show a similar problem and which seem quite recent: https://ask.libreoffice.org/en/question/151839/constant-crashes-of-libreoffice-603-1-in-kde-plasma/ https://www.reddit.com/r/kde/comments/8az9ac/constant_crashes_of_libreoffice_6031_in_kde_plasma/
To get a useful backtrace, you should install the debug packages provided by your distribution: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux I don't know how they are named in openSUSE. Arch Linux does not yet provide debug packages (but I hear they will soon). Would be good to hear, if these problems & crashes still occur with LibreOffice 6.1.x. I have never ran into these problems, even though I have been running with the named setup (KDE + Intel graphics) since early 2016.
It seems LibreOffice Writer has serious troubles in the most recent versions. It makes Linux systems (maybe only when working with KDE) crash in the most catastrophic way. First the screen gets blocked, you are not able to do anything, but moving the mouse cursor (interestingly this keeps working). After a few seconds, the screen goes to black and the system halts without any care for anything. I've gone through many forums. Changing memory assignation does not help. The failure tends to happen with non-trivial documents, independently of the size (seems more often with long documents, though). May be some relation with mark, copy, paste operations, but this is not sure either. Somebody reported that they had to go to an older version of LibreOffice and the trouble disapears, I am considering this possibility. In any case, I wonder how, I wonder why, LibreOffice team is not solving this catastrophic situation that is annoying so many people (just search to see how many cases of sudden crash are being reported). My configuration: OpenSuse Leap 42.3 (64 bits), kernel 4.4.162-78-default KDE Plasma 5.8.7 LibreOfice 6.0.5.2, included in OpenSuse official distribution and later updated from official repositories Best regards, David
dgaladi: the below also for your information. (In reply to Buovjaga from comment #8) > To get a useful backtrace, you should install the debug packages provided by > your distribution: > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU. > 2FLinux > I don't know how they are named in openSUSE. Arch Linux does not yet provide > debug packages (but I hear they will soon). > > Would be good to hear, if these problems & crashes still occur with > LibreOffice 6.1.x. > > I have never ran into these problems, even though I have been running with > the named setup (KDE + Intel graphics) since early 2016.
Hi. I would be very pleased to help providing backtraces and whatever you need, but I do not know how to install debug packages for OpenSuse. If anybody can help, I will greatly appreciate this.
(In reply to dgaladi@telefonica.net from comment #11) > Hi. I would be very pleased to help providing backtraces and whatever you > need, but I do not know how to install debug packages for OpenSuse. If > anybody can help, I will greatly appreciate this. I found something: https://www.reddit.com/r/openSUSE/comments/6j261v/trying_to_install_debug_symbols/ Looks like the first step is activating this in YaST: Configuration > Repositories > Main Repository (DEBUG) Then I guess see what the build-id is for LibreOffice and run (replacing the correct id): zypper install -C "debuginfo(build-id)=3098c47e4e7aeac97c1c47c5624f0fb9a8f10074"
Sincere thanks. I will try this as soon as I will have some time. This morning I have experienced already one catastrophic system crash due to this bug.
(In reply to dgaladi@telefonica.net from comment #13) > Sincere thanks. I will try this as soon as I will have some time. This > morning I have experienced already one catastrophic system crash due to this > bug. any update ?
(In reply to Xisco Faulí from comment #14) > (In reply to dgaladi@telefonica.net from comment #13) > > Sincere thanks. I will try this as soon as I will have some time. This > > morning I have experienced already one catastrophic system crash due to this > > bug. > > any update ? No. As a normal user, I did not get to manage at all with debug packages and so on. For the moment, I found an interesting and flawless workaround that I sincerely recommend to anybody experiencing this trouble: I installed Virutal Box, in my OpenSuse system. Then I set up a Windows 7 virtual machine, and I am processing my documents there with Microsoft Windows. No trouble with this, up to now.
Dear zeitlinie@yahoo.de, dgaladi@telefonica.net KDE4 support has been dropped in LibreOffice 6.3. Could you please try to reproduce it with LibreOffice 6.3 Beta1 from https://wiki.documentfoundation.org/QA/GetInvolved#Test_Pre-releases ? You can install it alongside the standard version.
Dear zeitlinie, 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
Dear zeitlinie, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp
So the bug is still there in 07/2022 with LO 7.3.4.2 (sorry for reopening). And I can reproduce it. On Linux running on a Ryzen with build in Radeon GFX using the MESA Radeon driver. I think it should "work" on intel Mesa drivers too. Reproducable in KDE and in XFCE at least. - Install ocl-icd and maybe optionally libclc and opencl-mesa (package names from Arch Linux, may be different on other distros) - Create a new user (so no ~/.config/libreoffice exists or just remove ~/.config/libreoffice). - start soffice with the new user. For some seconds nothing will happen. Your may even CTRL C soffice and doing some other commands manually. Suddenly the whole computer will get a black screen, even changing to a TTY isn't possible - it's dead. You have to force a poweroff or a hard reboot. Reboot. Hope the filesystem still works after the hard poweroff. Look for GraphicsRenderTests.log underneath ~/.config/libreoffice/... it doesn't exist. The rest of the settings seem to be there. Uninstall ocl-icd Start LibreOffice now. It works. So the opencl-icd loader is killing it. Maybe LO "automatically" probes for Opencl compliance when no settings are found before writing its settings profile? As soon as the settings are there and the "OpenCl"-Checkbox is not ticked within the LO settings, LO just works. Even with opencl-icd installed.
(In reply to Herr Irrtum! from comment #19) > So the bug is still there in 07/2022 with LO 7.3.4.2 (sorry for reopening). > > And I can reproduce it. On Linux running on a Ryzen with build in Radeon GFX > using the MESA Radeon driver. I think it should "work" on intel Mesa drivers > too. > Reproducable in KDE and in XFCE at least. > > - Install ocl-icd and maybe optionally libclc and opencl-mesa (package > names from Arch Linux, may be different on other distros) > - Create a new user (so no ~/.config/libreoffice exists or just remove > ~/.config/libreoffice). > - start soffice with the new user. > > For some seconds nothing will happen. Your may even CTRL C soffice and doing > some other commands manually. > Suddenly the whole computer will get a black screen, even changing to a TTY > isn't possible - it's dead. You have to force a poweroff or a hard reboot. > > Reboot. Hope the filesystem still works after the hard poweroff. > Look for GraphicsRenderTests.log underneath ~/.config/libreoffice/... it > doesn't exist. The rest of the settings seem to be there. > > Uninstall ocl-icd > > Start LibreOffice now. It works. > > So the opencl-icd loader is killing it. Maybe LO "automatically" probes for > Opencl compliance when no settings are found before writing its settings > profile? > As soon as the settings are there and the "OpenCl"-Checkbox is not ticked > within the LO settings, LO just works. Even with opencl-icd installed. Thanks for the information, but I think you should create a new report as it does not sound related to this report at all. There is nothing in this existing report about OpenCL.