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.



LINUX
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
Version: 5.3.3.2
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

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:
Version: 5.3.3.2
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

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.

Yeah, this should be bumped up.

Affects me on Solus as well. Lenovo X260, i7, 16Gb RAM, 500gb SSD

I am also affected, on openSUSE Tumbleweed.

Version: 5.3.3.2
Build ID: 30m0(Build:2)

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.

I think this might give more insight to developers:
https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_callgrind_trace

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 MALLOC_CHECK_
unset MALLOC_PERTURB_
unset G_SLICE
export SAL_DISABLE_FLOATGRAB=1
export OOO_DISABLE_RECOVERY=1
export SAL_DISABLE_GL_WATCHDOG=1
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

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.

Given Comment #9 lets assume this is that fixed bug in glib2

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.

Peter: see previous comment.

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.

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.

I just wanted to add here, for anyone bumping into this like me, that glib-2.54.3 makes this issue return.

The previous patch that fixed this issue in glib was reverted in 2.54.3, see

https://git.gnome.org/browse/glib/commit/?h=glib-2-54&id=4976e8109045b8aa72598668b809418d13e1f031

Reverting, the revert of the patch resolves the issue again.

*** Bug 114987 has been marked as a duplicate of this bug. ***

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

hello

problem here, with Debian Sid Cinnamon

libreoffice Version: 5.4.4.2 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 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887404

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
http://linuxfr.org/forums/linux-general/posts/libreoffice-consommation-anormale-du-cpu#comment-1726803

thank you

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.

Okay
therefore more than wait until the release of libreoffice 6

so it's not useful that I report the bug here
https://bugzilla.gnome.org/show_bug.cgi?id=761102

sorry for inconvenience
goodbye

Hi,

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.

Cheers,
Tony

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.

Cheers 
Melissa.