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: 220.127.116.11, 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.
Created attachment 136507 [details]
Created attachment 136508 [details]
Created attachment 136509 [details]
screen photo at 'systemctl isolate multi-user.target'
The same happens to me. KDE Session crashes with Libreoffice 18.104.22.168
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
- 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 22.214.171.124 seems to be working again:
try to update your kernel, it can help
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 126.96.36.199. 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:
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).
OpenSuse Leap 42.3 (64 bits), kernel 4.4.162-78-default KDE Plasma 5.8.7 LibreOfice 188.8.131.52, included in OpenSuse official distribution and later updated from official repositories
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:
> 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 firstname.lastname@example.org 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 email@example.com 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
any update ?
(In reply to Xisco Faulí from comment #14)
> (In reply to firstname.lastname@example.org 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 email@example.com, firstname.lastname@example.org
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.
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:
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!
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