writer (soffice.bin) eats all the cpu after a while until save

asked 2020-08-22 13:17:35 +0200

rimrunner gravatar image

updated 2021-06-12 16:20:24 +0200

Alex Kemp gravatar image

After some time (15 minutes? 30 minutes? 45 minutes?) soffice.bin process starts to eat 100 % of cpu time (as seen with top utility). It stops after I save a document that is open. Autosave does not stop it, only the save command from the user.

Documents I use are text only, typically few dozen pages. I don't know if the problem appears with shorter documents. I use odt file format and default settings.

LibreOffice version: Kernel 4.19.118 hardware: Raspberry Pi 4, 4 GB OS: Raspbian (Raspberry Pi OS), 32-bit, based on Debian buster

Exactly the same problem appeared on IBM T43 computer with Slackware 14 (OS) and a bit older LibreOffice version

edit retag flag offensive close merge delete


Hello, does the same problem appear, when LO is run in Safe Mode?

igorlius gravatar imageigorlius ( 2020-08-31 21:51:47 +0200 )edit

Tried it and it happens also in Safe Mode.

rimrunner gravatar imagerimrunner ( 2020-08-31 22:42:47 +0200 )edit


  • Could you provide a document with which the behaviour can be reproduced. (add to question via edit)


  • Does user input have to happen or is the behavor independent from it, as far as you can tell/see?
  • Is there any other user started process running beside the desktop env.?
igorlius gravatar imageigorlius ( 2020-08-31 23:38:04 +0200 )edit

The problem happens even without any user input (beyond opening a new text document from the startup menu). I just tried it without typing a single character and it took 50 minutes before the issue appeared. I typically have Emacs and Firefox and terminal-emulators (using ssh) open at the same time.

rimrunner gravatar imagerimrunner ( 2020-09-01 11:23:39 +0200 )edit

First of thanks for the precise description

Now , just to get our testsetup the synced, did i understand correctly that for your latest test, you opened an empty document and waited (50 Minutes), while monitoring the cpu load?

igorlius gravatar imageigorlius ( 2020-09-01 14:05:06 +0200 )edit

Yes, you got it right.

The suspicious thing with this issue is that both setups I mentioned in the beginning (RPi4 with its official OS and IBM T43 with Slackware) are really slow compared to modern desktop computers (RPi4 roughly corresponds to year 2007 desktop computer, T43 is yet much slower). I'm pretty certain that the issue didn't occur with Lenovo Thinkcentre M55 (4 GB, Debian) which is what used to be a powerful desktop computer when it was released in 2006 (not sure how M55 compares to RPi4. All these systems have had 32-bit OS, though RPi4 and M55 have a 64-bit capable processor).

rimrunner gravatar imagerimrunner ( 2020-09-01 15:32:45 +0200 )edit

i was able to reprduce your findings. And i could also confirm, that saving the document seemed let the cpuload go down again. Very strange. I'll experiment a bit more with this.

I this behaviour could be classified as a bug and reported here: https://bugs.documentfoundation.org


After saving the docment once i have now left the vm running and in the hours i seems the cpu load has not spiked again.

I'll now try to open another document ans see if it really only happend when you open a document initally and do not save it.

igorlius gravatar imageigorlius ( 2020-09-02 18:32:00 +0200 )edit

My experience has been that the problem is persistent in a way that when I save a file (which usually has not been initially empty) by pressing ctrl+S, the cpu-spiking appears again after some time has passed.

rimrunner gravatar imagerimrunner ( 2020-09-02 22:37:09 +0200 )edit

well that seems a bit differnt from what i could observe. i will monitor it a bit longer and see if i can see similar pattern or not.

[update 1]
So i left the vm running through the night and the spike did not reaccure with a newly opened image, i will now try to restart LO and see if it happens again.

[update 2]
After restarting LO ... now the load is up again. So in my case it seems to be related to the first start and not saving the document for a certain period of time.

The other things you mentioned i can not confirm, sorry. But in my experience it would be good not to jump to conclusions. Just report you/our findings as a bug in the most details possible ans see what the devs think about it. The easier it is to reproduce, the better ...(more)

igorlius gravatar imageigorlius ( 2020-09-02 23:50:19 +0200 )edit

I just filed an official bug report

rimrunner gravatar imagerimrunner ( 2020-09-06 14:37:33 +0200 )edit