Using KDE at openSuSE Tumbleweed I can not start libreoffice.
Problem occurs on 2 computers.
Steps to Reproduce:
1.call "libreoffice" or "soffice" from console
Console writes "Cannot destroy paint device that is being painted"
Libreoffice Writer opens
User Profile Reset: No
Problem does only occur with KDE, gnome works, did updates.
What kde version do you use? (kde4 or kde5)
Could you give a try to https://wiki.documentfoundation.org/QA/FirstSteps?
If you still reproduce the crash, would it be possible you retrieve a backtrace? (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace)
I use KDE 5.15.2-1.1 and libreoffice 184.108.40.206-1.1.
I will try the first steps next weekend, work won't let me time before, sorry.
Please also try if it stops crashing with --norestore option that skips the document recovery dialog, i.e. 'soffice --norestore'
Try changing KDE widget styles too(KDE System Settings > Application Style > Widget Style), perhaps it crashes with some but works with others?
(just between us, I had this happening to me sometimes but I always attributed it to my own development work in progress, I use Breeze widget style for the record)
Hi Sandra Weddig,
Please try what is mentioned in comment 3 and give us feedback.
Setting to NEEDINFO
I did rename the user profile and tried the first steps, also trying a different KDE style. Nothing changed.
The following line appears ca. 15 times for a single try-start of libreoffice in the system log:
plasmashell: qt.qpa.xcb: QXcbConnection: XCB error: 2 (BadValue), sequence: 46484, resource id: 92274694, major code: 142 (Unknown), minor code: 3
Thank you Sandra for your feedback.
Would it be possible you retrieve a backtrace by following this link? (https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace)
Yes, I still install the avaible debuginfo packets and will add the backtrace when I'm finished.
Created attachment 150251 [details]
Thank you Sandra for the bt, it should help KDE experts to analyze this.
The backtrace suggests that the Breeze style is involved here, e.g. this line:
> #1 0x00007fffe74eefae in Breeze::Style::scrollBarSubControlRect
Can you attach the GDB trace when using another widget style? (to see whether it looks like the same problem)
Also, if you have the possibility to check whether the same crash happens with a current daily build of master as available at , that would be good very helpful to know, since I cannot reproduce the issue here (master build of LibreOffice on Debian testing, which has breeze 4:5.14.5-1).  describes how you can install that in parallel.
Let me confirm this in the meantime. I get crashes like this every once in a while (in development environment though) but I'm unable to reproduce reliably
I cannot reproduce the bug when using libreoffice via console. It does not open via icon. Which command do I have to use, so that I can do a new backtrace?
(In reply to Sandra Weddig from comment #13)
> I cannot reproduce the bug when using libreoffice via console. It does not
> open via icon. Which command do I have to use, so that I can do a new
If you're using the daily master builds, the following command should work (otherwise the path to the 'soffice.bin' needs to be adapted):
It'd be great if you could use a debug build of LibreOffice master (available at ) and also install the debug symbols for libQt5widgets.so in addition, to get an even more meaningful backtrace.
(In reply to Michael Weghorn from comment #14)
> If you're using the daily master builds, the following command should work
> (otherwise the path to the 'soffice.bin' needs to be adapted):
Ah, sorry, that won't automatically generate a backtrace. Does this work:
./LibreOfficeDev_220.127.116.11.alpha0_Linux_x86-64_archive/program/soffice --backtrace --writer
Created attachment 150422 [details]
New Backtrace libreoffice RC
I will try to install and a backtrace of libreoffice master debug in a few minutes.
Revert back version since it must correspond to earliest one.
Created attachment 150424 [details]
Masterbuild Backtrace libreoffice
Created attachment 150425 [details]
Different Windowstyle Backtrace libreoffice
I did add a new backtrace, one with a different window style and one of the debug masterbuild (this seems not to run, do I need a different JDK?).
(In reply to Sandra Weddig from comment #20)
> I did add a new backtrace, one with a different window style and one of the
> debug masterbuild (this seems not to run, do I need a different JDK?).
The easiest workaround is probably to just disable Java by temporarily starting with the gtk3 VCL plugin, i.e. set the environment variable SAL_USE_VCLPLUGIN=gtk3 before starting LibreOffice and then in "Tools" -> "Options" -> "Advanced" disable the checkbox for "Use a Java runtime environment".
I've set up an openSUSE Tumbleweed VM for testing and could reproduce the JDK issue, but unfortunately not the crash, which makes this hard to analyse.
Looking at the backtrace from comment 18 and the involved code, I'd guess that there's a division by zero (causing the "SIGFPE, Arithmetic exception"), possibly because all the variables in the divisor (i.e. "range" and "scrollbar->pageStep") are 0.
It would be interesting to have that verified, so it'd be of help if you could start the debug version (with the same widget style as for the backtrace in comment 19) with
gdb --args <SOME_PATH>/instdir/program/soffice.bin --writer
at which point a '(gdb)' prompt appears.
The command 'r' will start the program. If the same crash appears, it'd be good to print the values of the variables involved and the backtrace with these commands then:
thread apply all bt
and attach the result here. Since this is not really straightforward, please feel free to just leave out those steps and just attach the backtrace.
In the meantime, I had the same issue a few times, but couldn't reliable reproduce. Any idea what might help to reproduce this?
AFAICS, the relevant values for the 'QStyleOptionSlider option' variable being passed are set at  based on values passed to that method by the ImplControlValue param.
I can confirm this. For me everything stopped working with Tumbleweed 20190403. Libreoffice starts normally. As soon as one opens a menu, does page-down or opens the "about" to see the version, Libreoffice crashes.
It does not crash when using safe-mode. Then the menues can be opened. Even when started with strace, I haven't been able to get any reasonable information. My Libreoffice is 18.104.22.168
The problem is solved for me. Updates and a new user profile did the trick.
(In reply to Sandra Weddig from comment #23)
> The problem is solved for me. Updates and a new user profile did the trick.
Great, thanks for the update!
Closing as WORKSFORME then.
(In reply to Rigo Wenning from comment #22)
> I can confirm this. For me everything stopped working with Tumbleweed
> 20190403. Libreoffice starts normally. As soon as one opens a menu, does
> page-down or opens the "about" to see the version, Libreoffice crashes.
> It does not crash when using safe-mode. Then the menues can be opened. Even
> when started with strace, I haven't been able to get any reasonable
> information. My Libreoffice is 22.214.171.124
Not sure whether this is the same problem. Can you check whether this also happens with a fresh user profile and a current daily build of master from ?  describes how you can install that in parallel.
Please report a new bug if the issue is still there then, and also paste the information from "Help" -> "About LibreOffice" there.