Bug 108246 - 100% cpu usage with no open document
Summary: 100% cpu usage with no open document
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Not Assigned
Keywords: perf
: 114987 (view as bug list)
Depends on:
Reported: 2017-05-30 14:57 UTC by TexJoachim
Modified: 2018-01-19 19:35 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description TexJoachim 2017-05-30 14:57:23 UTC
LibreOffice uses 100% of cpu (in my case of one of my 7 cores) even when no document is open.

Steps to reproduce:
1. Open terminal.
2. Start LibreOffice with "soffice &"
3. Check with htop.

I use openSUSE Tumbleweed and have the same behaviour with from openSUSE as well as from LibreOffice.org.
I already tried with a fresh configuration, but it made no difference.

Steps to Reproduce:
1. Open terminal.
2. Start LibreOffice with "soffice &"
3. Check with htop.

Actual Results:  
100% cpu usage on one core.

Expected Results:
cpu usage according to document.

Reproducible: Always

User Profile Reset: Yes

Additional Info:

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Comment 1 Mike B 2017-05-30 21:51:13 UTC
I can confirm this same behavior in both Calc and Draw on Solus Linux. The CPU core is pegged at 100% when no file or file is open.

Ironically, opening the About Dialog returns CPU usage to normal.

cat /proc/version 
Linux version 4.9.30-29.lts (root@solus-build-server) (gcc version 6.3.0 (Solus) ) #1 SMP Sat May 27 10:29:10 UTC 2017

ABOUT Dialog
Build ID: 30m0(Build:2)
CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: gtk3; Layout Engine: new; 
Locale: en-US (en_US.utf8); Calc: group
Comment 2 TexJoachim 2017-05-31 16:14:02 UTC
I can confirm that opening the About or Settings dialog returns CPU usage to normal.

Also, LibreOffice 5.2.x shows the same behaviour.

Some more details on my system:

joachim@gogmazios:~|⇒  cat /proc/version
Linux version 4.11.2-1-default (geeko@buildhost) (gcc version 6.3.1 20170202 [gcc-6-branch revision 245119] (SUSE Linux) ) #1 SMP PREEMPT Sat May 20 18:13:12 UTC 2017 (03903d8)

joachim@gogmazios:~|⇒  uname -a
Linux gogmazios.home.local 4.11.2-1-default #1 SMP PREEMPT Sat May 20 18:13:12 UTC 2017 (03903d8) x86_64 x86_64 x86_64 GNU/Linux

About dialog:
Build-ID: 30m0(Build:2)
CPU-Threads: 8; BS-Version: Linux 4.11; UI-Render: Standard; VCL: gtk3; Layout-Engine: neu; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Comment 3 Mike B 2017-05-31 19:52:10 UTC
Does anyone else think this should be bumped up in priority? It seems that a 100% cpu usage bug present at all times, across many LibreOffice apps is something that should be addressed rather quickly.
Comment 4 TexJoachim 2017-05-31 20:00:55 UTC
Yeah, this should be bumped up.
Comment 5 Charles Belfield 2017-06-02 00:33:01 UTC
Affects me on Solus as well. Lenovo X260, i7, 16Gb RAM, 500gb SSD
Comment 6 phocean 2017-06-02 09:40:04 UTC
I am also affected, on openSUSE Tumbleweed.

Build ID: 30m0(Build:2)
Comment 7 TexJoachim 2017-06-02 12:14:05 UTC
So, at least two Tumbleweed users with kernel 4.11 and three users with an Intel i7 cpu. (There is one in my system, too.)

Anyone here with access to an older kernel (like the one from Leap 42.2)?
I ran that before changing to Tumbleweed and did not have the 100% cpu hog issue.
Comment 8 Buovjaga 2017-06-04 18:48:07 UTC
I think this might give more insight to developers:

The way I do it is I have this stored in a text file and then I just paste the whole thing into a terminal:

unset G_SLICE
valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes /path/to/program/soffice.bin --splash-pipe=0 

I guess let it chug there for a while and then close. The large callgrind file compresses quite well with tar.xz and should fit inside our 10MB attachment limit.

If you want to test older versions than 5.2: https://wiki.documentfoundation.org/Installing_in_parallel/Linux
Comment 9 Peter 2017-06-08 13:32:38 UTC
The issue appears to be in glib2 see https://git.gnome.org/browse/glib/commit/?id=9ba95e25b74adf8d62effeaf6567074ac932811c

After rebuilding glib2 with this patch, the issue was resolved.
Comment 10 Caolán McNamara 2017-06-09 08:33:15 UTC
Given Comment #9 lets assume this is that fixed bug in glib2
Comment 11 Sergey Kvachonok 2017-06-12 10:56:22 UTC
I have glib-2.52.2 installed which already has the commit posted above.

All LibreOffice programs still use 100% of a single core time even when run with no arguments.

I run 4.11.4 kernel on Sandy Bridge and Kaby Lake i7 CPUs.
Comment 12 Buovjaga 2017-06-12 11:03:54 UTC
Peter: see previous comment.
Comment 13 Sergey Kvachonok 2017-06-12 11:18:54 UTC
I'm sorry, I've accidentally confused 2.52.2 and 2.53.2.

The fix is only scheduled for 2.52.3.
Applying the patch manually fixed the problem.

I apologize for the inconvenience.
Comment 14 Peter 2017-06-12 14:41:42 UTC
I should have added this to the other comment (figured should save others from re-solving it), but basically in solving it for Solus, it was tracked to the glib2 update of 2.52.1 to 2.52.2 (so only 2.52.2 should cause the issue). Adding the patch to 2.52.2 fixed it.
Comment 15 Francisco Pina Martins 2018-01-12 11:20:08 UTC
I just wanted to add here, for anyone bumping into this like me, that glib-2.54.3 makes this issue return.
Comment 16 Peter 2018-01-12 12:38:18 UTC
The previous patch that fixed this issue in glib was reverted in 2.54.3, see


Reverting, the revert of the patch resolves the issue again.
Comment 17 Buovjaga 2018-01-13 17:34:13 UTC
*** Bug 114987 has been marked as a duplicate of this bug. ***
Comment 18 Caolán McNamara 2018-01-13 21:38:20 UTC
wrt of the return of this problem, it seems that master/6.0 is unaffected, just <= 5.4, so persumably Jan-Marek scheduler/idle changes are why master isn't affected. There are quite a lot of those changes though to needs work to identify which one, or combo, makes it not matter there
Comment 19 melissa 2018-01-17 10:36:33 UTC

problem here, with Debian Sid Cinnamon

libreoffice Version: Build ID: 1:5.4.4-1
Threads CPU : 8; OS : Linux 4.14; UI Render : default; VCL : gtk3; 
Local : en-us (en_us.UTF-8); Calc: group

a core of the cpu used at 100% constantly..
bug gone up here 

the problem was also present with ArchLinux Cinnamon, but has been resolved by an upgrade of glib2

this bug also concerns Mageia, and Antergos
see here

thank you
Comment 20 Buovjaga 2018-01-17 11:03:14 UTC
melissa: as you can see from comment 18, the problem is not seen in the soon-to-be-released 6.0.

The glib discussion is going on in https://bugzilla.gnome.org/show_bug.cgi?id=761102 but it is nice that it does not affect 6.0 anymore.
Comment 21 melissa 2018-01-17 17:47:57 UTC
therefore more than wait until the release of libreoffice 6

so it's not useful that I report the bug here

sorry for inconvenience
Comment 22 Tony 2018-01-19 17:42:33 UTC

If you really need to use any of the components of LibreOffice, and you can't wait for LO 6.0, you can avoid the CPU issue if you uninstall LibreOffice and, then, only install the component you need.
For instance, I just needed Calc and Writer. I uninstalled the whole LibreOffice thing, and installed only Calc and Writer. No CPU problem anymore. It must be some of the other components causing the issue.
I hope it helps.

Comment 23 melissa 2018-01-19 19:35:45 UTC
hi Tony

thanks for the tip, I'll try.
in fact, LO is essential at this time for the job, he works 10 hours per day.

otherwise I installed LO from the repository experimental, at my own risk.