Bug 115845 - CPU usage increases randomly while writer is minimized after it has been open for several hours
Summary: CPU usage increases randomly while writer is minimized after it has been open...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: x86-64 (AMD64) All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, notBibisectable, regression
Depends on:
Blocks:
 
Reported: 2018-02-19 10:05 UTC by Alexandre Bibeau
Modified: 2018-04-18 03:45 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
verysleepy profile during high CPU usage (13.81 KB, application/zip)
2018-03-17 05:22 UTC, Alexandre Bibeau
Details
longer verysleepy capture of offending thread in version 6.0.2 (37.49 KB, application/zip)
2018-03-21 07:36 UTC, Alexandre Bibeau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Bibeau 2018-02-19 10:05:43 UTC
Description:
If I leave writer open on some documents I'm working on (usually .docx, unreleased documents I'm not at liberty to share, unfortunately), CPU usage will start increasing (from 0% to around 20% of my cpu) at random times, even though it's minimized and I haven't touched it in hours. The usage is sufficient to drive up the fan speed on my laptop and to interfere with CPU demanding processes I may be running and that forces me to close writer. The documents are small in size and contain nothing complex, and certainly nothing that needs a significant amount of computation. I never had this problem working with the same files on my Libreoffice 5 installation on linux.

Steps to Reproduce:
1.Leave reasonable .docx open
2.Work a bit, add comments, etc.
3.Minimize, leave it alone for several hours

Actual Results:  
CPU usage increases unreasonably

Expected Results:
CPU usage should stay around 0%


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.0.1.1 (x64)
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
CPU threads: 8; OS: Windows 10.0; UI render: default; 
Locale: en-CA (en_CA); Calc: group


User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Comment 1 Imai 2018-02-20 09:24:41 UTC
Issue not reproduced.
I tried 3hours,but not around 20%.
---
OS X EL Capitan
Ver:10.11.3

version: 6.0.1.1
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
CPU threads: 4; OS:Mac OS X 10.11.3; UI render: default; 
local: ja-JP (ja.UTF-8); Calc: group
Comment 2 Alexandre Bibeau 2018-02-21 10:46:15 UTC
(In reply to Imai from comment #1)
> Issue not reproduced.
> I tried 3hours,but not around 20%.
> ---
> OS X EL Capitan
> Ver:10.11.3
> 
> version: 6.0.1.1
> Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
> CPU threads: 4; OS:Mac OS X 10.11.3; UI render: default; 
> local: ja-JP (ja.UTF-8); Calc: group

Sometimes is takes almost a day before it occurs. I have no idea what triggers it.
Comment 3 Tim 2018-03-06 10:16:55 UTC
I can confirm I also suffer from this, or a similar, bug.

In my case after a document has been left open for multiple hours or days Writer begins using 100% of a single CPU core.

I am using .odt documents of around 15k words, though the documents are mainly text.

This issue is new in Libreoffice 6.x and wasn't apparent in 4.x or 5.x.

Steps to reproduce
1. Open .odt file, 
2. Write, edit, add comments, etc.
3. Leave document open in background for hours / days. This will usually include suspending laptop on a number of occasions.

Result
CPU increases to ~100% of single core, fan spins up.

Expected result
CPU usage ~1%

Workaround
Close Writer

Version: 6.0.2.1
Build ID: 1:6.0.2~rc1-0ubuntu0.16.04.1~lo1 (Libre Office Fresh PPA)
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); Calc: group

OS: Ubuntu 16.04 LTS
Comment 4 Alexandre Bibeau 2018-03-09 17:50:51 UTC
I have also been able to replicate the bug with .odt documents. Again, they contain nothing special, just text and comments.
Comment 5 Buovjaga 2018-03-11 14:30:38 UTC
Ok, I guess we have to set to NEW, but it's darn hard to reproduce and investigate.
Comment 6 Alexandre Bibeau 2018-03-11 16:10:53 UTC Comment hidden (obsolete)
Comment 7 Buovjaga 2018-03-11 16:12:49 UTC Comment hidden (obsolete)
Comment 8 Telesto 2018-03-12 14:47:53 UTC
(In reply to Buovjaga from comment #7)
> (In reply to Alexandre Bibeau from comment #6)
> > (In reply to Buovjaga from comment #5)
> > > Ok, I guess we have to set to NEW, but it's darn hard to reproduce and
> > > investigate.
> > 
> > Is there some sort of diagnostics tool I can run? It happens fairly
> > consistently on my system.
> 
> Hmh, well there are debuggers, profilers and such, but I am not able to
> advise on their use. Especially in this sort of long running thing.

VerySleepy (Windows) is a very basic profiler, which could give some insight.. (no guarantees) 
http://www.codersnotes.com/sleepy/

1. Launch it when LibreOffice is using 100%
2. Select soffice.bin as process to profile
3. Select the top thread (probably the post active one)
4. Set profile for time set. And configure it to, say 30 seconds
5. Profile selected, wait until done
6. Select File -> Save As. and attach it
Comment 9 Alexandre Bibeau 2018-03-17 05:22:16 UTC
Created attachment 140667 [details]
verysleepy profile during high CPU usage

While soffice.bin was using about 65% of a core while minimized, here is what verysleepy recorded.
Comment 10 Alexandre Bibeau 2018-03-21 07:36:06 UTC
Created attachment 140765 [details]
longer verysleepy capture of offending thread in version 6.0.2

Another verysleepy capture, one thread was responsible for all the unwarranted cpu usage, I acquired samples for that thread during 60s.
Comment 11 Alexandre Bibeau 2018-03-21 07:39:00 UTC
Comment on attachment 140765 [details]
longer verysleepy capture of offending thread in version 6.0.2

The new verysleepy capture is from the libreoffice 6.0.2.1 release.
Comment 12 Telesto 2018-03-21 09:43:00 UTC
(In reply to Alexandre Bibeau from comment #11)
> Comment on attachment 140765 [details]
> longer verysleepy capture of offending thread in version 6.0.2
> 
> The new verysleepy capture is from the libreoffice 6.0.2.1 release.

Thanks for the effort! I can't really interpret it, sadly.. Hopefully someone else can.
Thinking about it, a Procdump dump might be helpful to.. 

@Timur
Is this a scenario where ProcDump could be useful? And if so, which type of command?
Comment 13 Timur 2018-03-21 11:40:44 UTC
I find procdump useful in Windows when:
- WinDBG doesn't give result for any reason
- there's a dump but not a crash
- you need a simpler tool for end user compared to WinDBG that needs to be set

CPU may not be related to dump but it's worth trying. 
Usage is simple, without installation: 
- get Sysinternals free suite 
- run Cmd (Command Prompt)
- run LO (single version that you need)
- run procdump: path-to\SYSINTERNALSSUITE\procdump.exe soffice.bin -option path-to\soffice.bin.dmp

"-option" is generally "-h" to write dump if process has a hung window and that's what I use regularly 
But "-p" could be tried here, I didn't use it before. 
I guess we should have a wiki on this, which tool to use when. 

Dump is than analyzed in WinDBG via File-Open crash dump.

Missing in this bug is an example of document that gives consistent high CPU.
Comment 14 Alexandre Bibeau 2018-04-13 21:31:36 UTC Comment hidden (obsolete)
Comment 15 Buovjaga 2018-04-14 17:16:34 UTC Comment hidden (obsolete)
Comment 16 Alexandre Bibeau 2018-04-18 03:45:11 UTC
(In reply to Buovjaga from comment #15)
> (In reply to Alexandre Bibeau from comment #14)
> > In the meantime, what do I do with that 1GB dump?
> 
> How small does it get, if you compress it using .tar.xz?

It brings it down to about 125MB, still too big for bugzilla, but I could upload it somewhere else.