soffice.bin (LibreOffice) is pegging a cpu to 100%

English Applications
1

Anyone else having a problem with soffice.bin (LibreOffice) pegging a cpu to 100% ? This is occuring for both Calc and Writer (haven’t checked anything else).

Interestingly, if I open a sub window, such as the “save as” or via “bullets and numbering” or etc. etc. etc., cpu usage drops back to normal (i.e. 1% range). But as soon as the sub window is closed, and focus is restored to the main window of the respective app (calc, writer), then a cpu gets pegged again.

This really blows goats. Waste of energy and highly distracting (noise from cpu fan kicking into overdrive).

2

PS – this problem surfaced since yesterday evening when I pulled in a whack of updates … libreoffice 5.3.3.2 being amongst them

3

Hi
I see it, running perf with say calc running one cpu is pegging at ‘read_hpet’.


zypper in perf
perf record -F 250 -g -a sleep 10
perf report
4

Someone has a bug report up, albeit its not exactly what is happening here. My suspicion is that the bug they’ve reported falls under the wider scope that I highlight here. I’m under a hard deadline for the next two weeks, so can’t waste any more time on it (its timing couldn’t have been worse given my reliance on calc and writer during this period).

I note that I have a real lousy work around – if I open up a “save as” dialogue on another (LibreOffice) document I can work away on other documents. CPU usage drops (but strangely only to ~15%). And, unfortunately, as soon as you open up a sub window in the doc you’re working on (like bullets, highlight colours etc), the save as sub window on your “dummy” doc is lost and the CPU becomes pegged again … necesitating a constant reopening of the save as on the dummy doc … told ya it was a lousy workaround … its okay if you’re just typing, but as soon as you start messing with formating, it becomes a PITA.

Anyway: https://bugzilla.suse.com/show_bug.cgi?id=1040546

5

For a quick and dirty stopgap solution what about reverting to an earlier version? There’s version 5.1.3.1 for tumbleweed at https://build.opensuse.org/package/show/home%3Ak0da%3Aappdata/libreoffice under https://software.opensuse.org/package/libreoffice

6

Something else you may try is changing the default dialog box in Tools > Options > General, tick (or untick) “Use LibreOffice Dialog Boxes”. I vaguely remember a similar problem some time ago regarding KDE dialogs, this would fix it.

7

Thanks for the suggestions. This one, unfortunately, had no effect (either toggled on or off). I’ll look into the older package(s) as an option. Cheers

8

Something else that happened about 2 years ago was, if you started a new document but didn’t name it (by saving to disk), in a few minutes you’d start getting constant disk and cpu activity making the desktop very unresponsive , as libreoffice would keep writing “unnamedxxx.odt” in the LO tempsave folder, or something like that. This was fixed in a subsequent release.

I’ve had problems with LO (with documents open) would interfere with something else. I had to switch from vmware player to virtualbox because, when having both open, vmware would constantly become unresponsive for up to 30 seconds, without cpu, network or disk activity. If I closed LO the problem stopped. At the time I thought it could be related to hugepage settings, but couldn’t find a consistent fix.

9

That was also related to KDE extensions for LO - changing to GTK extensions at the time fixed it, but with clashing themes.

Of course all this is old news, although sometimes these (or similar) bugs resurface.

10

Hello, I’m see the same general problem of very high CPU usage from soffice.bin (about 25% of a CPU core) whenever LibreOffice is opened, even if a blank document. It doesn’t matter if it’s Writer or Calc or Impress. It’s enough to make my fan speed kick up noticeably. It appeared with the update to Tumbleweed that included 5.3.3.2

11

On Mon 29 May 2017 04:16:01 PM CDT, sb56637 wrote:

Hello, I’m see the same general problem of very high CPU usage from
soffice.bin (about 25% of a CPU core) whenever LibreOffice is opened,
even if a blank document. It doesn’t matter if it’s Writer or Calc or
Impress. It’s enough to make my fan speed kick up noticeably. It
appeared with the update to Tumbleweed that included 5.3.3.2

Hi All
A fix is on the way…

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.62-18.6-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

12

I did an early test for that fix and it did not help. What did help myself and several others was to force Libre Office to use a different visual toolkit. You can achieve this by launching it via

$ SAL_USE_VCLPLUGIN=gen libreoffice

or by adding the following lines to ~/.bashrc ( or another location which prepares the user’s environment )

export SAL_USE_VCLPLUGIN=gen

That does have the side effect of looking worse ( IMO at least ) but for now this is the only reliable workaround.

13

Installed a bunch of updates yesterday and the issue now seems to be resolved … didn’t spot anything related to Libreoffice, so perhaps there was a toolkit update (in relation to what Robert mentioned) … whatever. happy that its working again.

14

Son of a … Seriously? I mean seriously?

I installed a large number of updates tonight and I’ll give you zero guesses as to which problem has re-emerged.

15

Its not the same issue (though certainly is characterised by the same end result) … have discovered this morning that it is related to docs with external links. One, in particular, seems to be a bit of a trouble maker. Last night the cpu usage was pegged in perpituity, but this morning, it drops to normal after a short while. Not sure why today has brought about a differing behaviour.

Anyway, carry on…

16

Sorry for interrupting but this post solved my problem (https://bugs.documentfoundation.org/show_bug.cgi?id=107772), which is contrary to this one (very high CPU usage while keeping save/open dialog opening but normal in other time).