Bug 121356 - One CPU used at 100% with no document opened, until mouse passing over window (gtk2)
Summary: One CPU used at 100% with no document opened, until mouse passing over window...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.3.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: CPU-AT-100% GTK2
  Show dependency treegraph
 
Reported: 2018-11-11 20:16 UTC by Miguel
Modified: 2019-10-01 17:12 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Miguel 2018-11-11 20:16:56 UTC
Description:
When LibreOffice is launched but NOT being used, including when no document at all is opened, one CPU core gets used at almost 100% after some time (approx. 1 minute), by the process "soffice.bin".

When I show the LibreOffice window (using the task bar on the window manager), nothing changes. No change, either, when I move the mouse on the title bar (File, Tools, Help), or on the left column (Open a file, Distant files, Recent files,...).

However, whenever I move the mouse over any of the recent file icons, displayed in the main part of the window when no document is opened, the CPU usage goes to 0,0%. Moving the mouse over the gray area between the icons has no effect, the CPU goes down only when the mouse is over an icon (icon displayed with a bright frame and an "X" in the upper-right corner).

After a while (I measured a delay of 39 minutes, then a delay of 12 minutes: it seems somewhat random), the CPU suddenly goes to 100% once again.

I just tested it on LibreOffice 6.1, but I observe a similar behavior on much earlier versions, sure for 5.4, but probably it comes from much before.

I think it happens every time, but the delay is so long that it might be difficult to tell for sure.

I tried to leave for hours, in case it would be due to some background work such as indexing or compiling, but the CPU use stays at 100% even after several hours.

Steps to Reproduce:
1. Launch LibreOffice
2. Use Calc to do some work
3. Close all documents
4. Leave LibreOffice idle, take care not to move the mouse over its window
5. Wait for some time (1 hour is usually sufficient)
6. Type "top" (on Linux) and see that soffice.bin is using almost 100% of one CPU

Actual Results:
soffice.bin: CPU use = 90% to 100%

Expected Results:
soffice.bin: CPU use = 0%


Reproducible: Always


User Profile Reset: No


OpenGL enabled: Yes

Additional Info:
Version: 6.1.3.2
Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb
Threads CPU : 2; OS : Linux 4.15; UI Render : par défaut; VCL: gtk2; 
Locale : en-IE (fr_FR.UTF-8); Calc: group threaded
Comment 1 Xisco Faulí 2019-01-22 16:13:26 UTC
Does it work if you disable OpenGl ? -> https://wiki.documentfoundation.org/OpenGL

I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the issue is still present
Comment 2 Miguel 2019-01-22 20:53:06 UTC
Actually, OpenGL was already disabled.

I tried with OpenGL enabled or disabled, and got exactly the same result: after a few tens of minutes, the CPU use goes to 100% (of one core out of two), until the mouse goes over some widget in LibreOffice.
Comment 3 Buovjaga 2019-07-13 15:58:07 UTC
(In reply to Miguel from comment #0)
> Additional Info:
> Version: 6.1.3.2
> Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb
> Threads CPU : 2; OS : Linux 4.15; UI Render : par défaut; VCL: gtk2; 
> Locale : en-IE (fr_FR.UTF-8); Calc: group threaded

I see you have gtk2 there. What if you use gtk3? Which Linux distribution are you using? I think they should all ship builds with the gtk3 backend now.

To force a specific backend, you can launch from the command line with
SAL_USE_VCLPLUGIN=gtk3 libreoffice

or

SAL_USE_VCLPLUGIN=gtk libreoffice

Then inspect Help - About: VCL to confirm.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Comment 4 Miguel 2019-07-14 13:33:42 UTC
I am using Xubuntu, the Ubuntu variant based on XFCE instead of Gnome 3 (which was far too heavy for an old PC such as mine: this was the reason for my switch from Ubuntu to Xubuntu, many years ago).
I have Xubuntu 18.04 "Long time support". Xubuntu has XFCE 4.12, which is based on gtk2. It seems that XFCE 4.14 should be compatible with gtk3, but its release is being delayed since years.

I will try what you are suggesting within a few days, when I have time and access to my PC.
Comment 5 Miguel 2019-07-14 13:47:12 UTC
One additional remark: Xunbutu 19.04 now uses Xfce 4.13 and gtk3. But it runs only in 64 bit, which I am reluctant to install because my PC is already at its maximum of RAM, so I do not plan to move to that before about one year, when Xubuntu 20.4 "long time support" is released. LibreOffice too will drop the 32 bit support, anyway. The bad news is that with 64 bit, even if the bug is solved, my PC may because unusable.
Comment 6 Buovjaga 2019-07-14 13:59:48 UTC
Ok, in that case I suggest you test with

SAL_USE_VCLPLUGIN=gen libreoffice

which uses the fallback UI backend ("generic").
Comment 7 Miguel 2019-07-16 22:47:05 UTC
I have tried
  SAL_USE_VCLPLUGIN=gen libreoffice
After waiting for over 2 hours, the bug did not appear: the CPU used stayed very low. It seems to confirm your hypothesis.

Command: SAL_USE_VCLPLUGIN=gen libreoffice

About: Version: 6.1.6.3
Build ID: 5896ab1714085361c45cf540f76f60673dd96a72
Threads CPU : 2; OS : Linux 4.18; UI Render : default; VCL: x11; 
Locale : en-IE (fr_FR.UTF-8); Calc: group threaded

uname -a : Linux xxxxxx 4.18.0-17-generic #18~18.04.1-Ubuntu SMP Fri Mar 15 15:26:32 UTC 2019 i686 i686 i686 GNU/Linux

lsb_release -a : Ubuntu 18.04.2 LTS
Comment 8 Buovjaga 2019-07-17 03:20:08 UTC
Thanks for testing.

The good thing is that 4.14 is finally supposed to be released later this summer: https://simon.shimmerproject.org/2019/07/01/xfce-4-14pre2-released/
"The next release – aka pre3 – is optional, so we may decide to skip it and go straight for the final release if the release team is confident that there are no showstoppers."

From a comment:
"In theory distributions can decide to disable Gtk+2 already. However there are still some applications that rely on the libraries that are not yet ported to Gtk+3 (see the Roadmap page, e.g. Ristretto) so those would be broken by that change.

As soon as we have stable releases of all applications in a Gtk+3 version we will probably remove Gtk+2 support altogether.
For the panel we will at least disable Gtk+2 support by default upstream as there are only very few unported plugins."
Comment 9 Xisco Faulí 2019-08-19 09:56:08 UTC
XFCE 4.14 was released a week ago < https://www.xfce.org/about/news/?post=1565568000 >
@Miguel, Would you mind testing this bug again with that version ?
Comment 10 Miguel 2019-08-21 21:29:25 UTC
Sorry, I cannot try with Xfce 4.14, it is only on 64 bits, and I have a PC with Linux 32 bits and not enough RAM for 64 bit.
Comment 11 Buovjaga 2019-08-22 03:16:46 UTC
(In reply to Miguel from comment #10)
> Sorry, I cannot try with Xfce 4.14, it is only on 64 bits, and I have a PC
> with Linux 32 bits and not enough RAM for 64 bit.

Note: this is referring to Xubuntu, which does not offer 32-bit ISOs and packages anymore.
Comment 12 mattia.b89 2019-09-07 12:54:21 UTC
I am not able to reproduce the bug.

Version: 6.3.1.2
Build ID: 6.3.1-1
CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk2; 
Locale: it-IT (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded
Comment 13 Buovjaga 2019-10-01 17:12:19 UTC
Gtk2 was dropped, closing