Bug 118991 - EDITING. 100% CPU usage after a few minutes with certain documents.
Summary: EDITING. 100% CPU usage after a few minutes with certain documents.
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: CPU-AT-100%
  Show dependency treegraph
 
Reported: 2018-07-30 07:14 UTC by laurens
Modified: 2019-10-08 07:54 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file exhibiting behavior (79.50 KB, application/msword)
2019-05-09 23:31 UTC, ross.stormcrow
Details
Sample screenshot showing time in function calls when 100% CPU (1.44 MB, image/png)
2019-09-03 09:07 UTC, laurens
Details

Note You need to log in before you can comment on or make changes to this bug.
Description laurens 2018-07-30 07:14:24 UTC
Since at least LO 6.0 some documents cause 100% CPU usage when they are open for a few minutes.

After scrolling through the document from top to bottom reduces the CPU usage to normal levels for a few minutes, but then the CPU gets back to 100%.

This is a deal-breaker for using LO on my laptop

OS: macOS High Sierra. 

Profile: I recently made a new profile - no change

Document: happens in a work document, so I cannot share. It is quite a complex document (quite a few included PNG files) - 6MB total doc. size, about 77 pages

I have the process sampled - include an extract here. Seems like the AquaSalTimer takes a lot of time?

Sampling process 1307 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling soffice (pid 1307) every 1 millisecond
Process:         soffice [1307]
Path:            /Applications/LibreOffice.app/Contents/MacOS/soffice
Load Address:    0x109f9c000
Identifier:      org.libreoffice.script
Version:         6.0.5002 (6.0.5002)
Code Type:       X86-64
Parent Process:  ??? [1]

Date/Time:       2018-07-30 08:58:55.994 +0200
Launch Time:     2018-07-30 08:50:39.223 +0200
OS Version:      Mac OS X 10.13.6 (17G2208)
Report Version:  7
Analysis Tool:   /usr/bin/sample

Physical footprint:         355.7M
Physical footprint (peak):  482.8M
----

Call graph:
    2577 Thread_28540   DispatchQueue_1: com.apple.main-thread  (serial)
    + 2577 start  (in libdyld.dylib) + 1  [0x7fff686b8015]
    +   2577 main  (in soffice) + 16  [0x109f9cf50]
    +     2577 soffice_main  (in libsofficeapp.dylib) + 230  [0x10a050c36]
    +       2577 SVMain()  (in libvcllo.dylib) + 40  [0x10d88c348]
    +         2577 ImplSVMainHook(int*)  (in libvcllo.dylib) + 353  [0x10d8f8ef1]
    +           2577 NSApplicationMain  (in AppKit) + 804  [0x7fff3dd03a72]
    +             2577 -[NSApplication run]  (in AppKit) + 812  [0x7fff3dd348b5]
    +               2577 -[VCL_NSApplication sendEvent:]  (in libvcllo.dylib) + 79  [0x10d952b4f]
    +                 2577 AquaSalInstance::handleAppDefinedEvent(NSEvent*)  (in libvcllo.dylib) + 159  [0x10d8f9caf]
    +                   2577 ImplSVMain()  (in libvcllo.dylib) + 91  [0x10d88b73b]
    +                     2577 desktop::Desktop::Main()  (in libsofficeapp.dylib) + 2764  [0x10a02062c]
    +                       2577 Application::Execute()  (in libvcllo.dylib) + 256  [0x10d886150]
    +                         2575 ImplYield(bool, bool)  (in libvcllo.dylib) + 73  [0x10d886249]
    +                         ! 1825 AquaSalInstance::DoYield(bool, bool)  (in libvcllo.dylib) + 720  [0x10d8fa510]
    +                         ! : 1816 AquaSalTimer::callTimerCallback()  (in libvcllo.dylib) + 64  [0x10d8fd800]
    +                         ! : | 1390 Scheduler::ProcessTaskScheduling()  (in libvcllo.dylib) + 568  [0x10d877d78]
    +                         ! : | + 1324 sw::DocumentTimerManager::DoIdleJobs(Timer*)  (in libswlo.dylib) + 535  [0x18c7e72a7]
    +                         ! : | + ! 1166 SwViewShell::LayoutIdle()  (in libswlo.dylib) + 338  [0x18cc4d5d2]
    +                         ! : | + ! : 571 SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*)  (in libswlo.dylib) + 129  [0x18c977be1]
    +                         ! : | + ! : | 333 SwLayIdle::DoIdleJob(SwLayIdle::IdleJobType, bool)  (in libswlo.dylib) + 216  [0x18c977888]
    +                         ! : | + ! : | + 177 SwContentFrame::ImplGetNextContentFrame(bool) const  (in libswlo.dylib) + 171  [0x18c94c55b]
    +                         ! : | + ! : | + ! 52 SwFrame::IsContentFrame() const  (in libswlo.dylib) + 54  [0x18c6ca466]
    +                         ! : | + ! : | + ! : 29 o3tl::typed_flags<SwFrameType>::Wrap operator&<SwFrameType>(SwFrameType, o3tl::typed_flags<SwFrameType>::Wrap)  (in libswlo.dylib) + 53,37,...  [0x18c6cc265,0x18c6cc255,...]
    +                         ! : | + ! : | + ! : 17 o3tl::typed_flags<SwFrameType>::Wrap operator&<SwFrameType>(SwFrameType, o3tl::typed_flags<SwFrameType>::Wrap)  (in libswlo.dylib) + 50  [0x18c6cc262]
    +                         ! : | + ! : | + ! : | 9 o3tl::is_typed_flags<SwFrameType, 64511>::Wrap::Wrap(int)  (in libswlo.dylib) + 7,1,...  [0x18c6cc317,0x18c6cc311,...]
    +                         ! : | + ! : | + ! : | 8 o3tl::is_typed_flags<SwFrameType, 64511>::Wrap::Wrap(int)  (in libswlo.dylib) + 4  [0x18c6cc304]
    +                         ! : | + ! : | + ! : 5 o3tl::typed_flags<SwFrameType>::Wrap operator&<SwFrameType>(SwFrameType, o3tl::typed_flags<SwFrameType>::Wrap)  (in libswlo.dylib) + 37  [0x18c6cc255]
    +                         ! : | + ! : | + ! : | 5 o3tl::is_typed_flags<SwFrameType, 64511>::Wrap::operator int() const  (in libswlo.dylib) + 4,1,...  [0x18c6cc2f4,0x18c6cc2f1,...]
    +                         ! : | + ! : | + ! : 1 o3tl::is_typed_flags<SwFrameType, 64511>::Wrap::Wrap(int)  (in libswlo.dylib) + 5  [0x18c6cc305]
    +                         ! : | + ! : | + ! 48 SwFrame::IsContentFrame() const  (in libswlo.dylib) + 45  [0x18c6ca45d]
Comment 1 Alex Thurgood 2018-07-30 08:11:47 UTC
@laurens : we would really need a small sample document to be able to reproduce the problem.

From your profiling, I see calls to IsContentFrame() 

1) are you using lots of frames in your document ?

2) what does each frame contain (content / formatting / legends / spacing / padding) ?
Comment 2 laurens 2018-07-30 08:25:28 UTC
Unfortunately I don't know what frames are (I can see the menu item - never used it in 10years of LO/OO/StarOffice use).

I have about 20 2x1 tables with PNGs inserted and associated captions and perhaps 30 "normal" text tables (5x5 or so). PNGs are mostly 1600x1000 

I deleted the picture in the headers, but that had no effect. 

Is there somewhere I can get document stats that might be useful for debug (e.g. no of frames, no of objects, etc)?
Comment 3 laurens 2018-07-30 09:14:52 UTC
Ah - I see that Frames are autocreated when I add captions to graphics - in that case I have about 30 frames...
Comment 4 Alex Thurgood 2018-07-30 09:51:22 UTC
The CPU usage might be due to Writer attempting to refresh the screen display layout constantly (I seem to remember that this happened a lot with inserted images) and perhaps this is triggered more or compounded by the presence of the frames.

Ideally, we would still need a minimalist sample document where the problem could be seen.
Comment 5 laurens 2018-07-30 09:59:53 UTC
I've tried to make a smaller redacted document, but of course this is not showing the problematic behaviour. As this is a work document, it is unfortunately out of the question to share :/

A lot of the images are scaled - I wonder if that might be causing a problem? 

The problem is that this a showstopper for me to use LO at the moment due to this issue as I need battery life...
Comment 6 Telesto 2018-07-30 20:36:28 UTC
(In reply to laurens from comment #5)
> I've tried to make a smaller redacted document, but of course this is not
> showing the problematic behaviour. As this is a work document, it is
> unfortunately out of the question to share :/
> 
> A lot of the images are scaled - I wonder if that might be causing a
> problem? 
> 
> The problem is that this a showstopper for me to use LO at the moment due to
> this issue as I need battery life...

LibreOffice 6.1 has some image handling improvements. It might fix the issue.
Comment 7 laurens 2018-07-31 06:58:29 UTC
I will try that - unfortunately it's crunch time so it will take a week or two for me to have a chance to follow up on this...
Comment 8 Jean-Baptiste Faure 2018-07-31 12:38:47 UTC
What is the format of your text document? .odt or .docx ?

Best regards. JBF
Comment 9 Xisco Faulí 2018-08-31 19:32:05 UTC
(In reply to Jean-Baptiste Faure from comment #8)
> What is the format of your text document? .odt or .docx ?
> 
> Best regards. JBF

Dear laurens@norbit.no,
Could you please answer the question above in order to help us triage this issue?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' once the question has been answered
Comment 10 laurens 2018-09-03 07:10:52 UTC
I deleted my profile and ran both 6.0.5 and 6.1.0 on macOS and the system behaved well for a while (no excessive CPU use).
I did try redoing one of the tables (and frame) on the first page at the same time. 

But it seems that the problem has returned last week, it's possible that a colleague has edited in Word 2016 (but not sure - and he cannot remember)
Comment 11 Xisco Faulí 2018-09-13 10:14:32 UTC
(In reply to laurens from comment #10)
> I deleted my profile and ran both 6.0.5 and 6.1.0 on macOS and the system
> behaved well for a while (no excessive CPU use).
> I did try redoing one of the tables (and frame) on the first page at the
> same time. 
> 
> But it seems that the problem has returned last week, it's possible that a
> colleague has edited in Word 2016 (but not sure - and he cannot remember)

So it worked well for a while and suddenly the problem arose again?
Do you remember doing any action to trigger it ?
Comment 12 laurens 2018-09-20 20:12:21 UTC
No, I cannot think of anything that may cause it. Currently running  6.1.0.2 on macOS 12.3.6

I have an old StarOffice document with a lot of frames that does the same thing (100% CPU after a while, back to 0% CPU if I scroll to all the way through the document to the first page). That document will never have been converted to MS Word, so I don't think that docx contamination is a root cause.

Unfortunately the docs that show this behaviour are from work, thus I cannot share. 

I have a sample document that may be able to share - I cannot confirm that it has the same problem exactly - but it uses up to 50% CPU whilst typing according to Activity Monitor and everything feels slightly "sluggish". When I move a picture to a page below then the CPU usage drops to 20-30% whilst typing.

I also have the Activity Monitor sample of the threads executing when there is high CPU usage whilst typing.

Can that be of use?
Comment 13 Eltomito 2018-09-30 18:21:07 UTC
The same bug affects me too on Xubuntu 16.04 with LibreOffice 6.0.6.2, except scrolling through documents doesn't help. When I open a document, doesn't matter how big or small, after a while, LibreOffice runs up its CPU usage to around 100%, the fan is running all the time, battery is draining quickly.

My laptop is Lenovo G570, Intel i5-2430M.

Is there a way I can find out what LO is actually doing to help debug it?
Comment 14 laurens 2018-10-23 18:23:51 UTC
LO 6.1.2.1 on macOS 10.13.6 

Still getting this on various documents - as well as general slowness on documents that don't spin to 100% CPU usage (see https://bugs.documentfoundation.org/show_bug.cgi?id=120727).

Not quite sure how I can help debug - can send process samples and was able to isolate and upload a document for 120727.

The documents that pertain to this bug are work documents that cannot be shared unfortunately.
Comment 15 laurens 2018-10-23 18:25:00 UTC
The documents that give me problems are, AFAIK pure .odt documents as well (i.e. have never been through docx)
Comment 16 Alex Thurgood 2019-01-21 09:02:04 UTC
@laurens : if you can't provide us the problematic documents due to confidentiality issues - which we fully understand of course, can you provide us some information on the structure of the document :

 - page formatting ?
 - number of pages - forced page breaks or natural pagination ?
 - tables; if any, with examples of structure of table ?
 - images : type, format, resolution, anchoring - framed or not ?
 - any legends or numbering for the illustrations ?
 - document, page, heading, font styles used ?
 - automatic spellchecking - langpacks ?
Comment 17 laurens 2019-01-23 18:10:19 UTC
I will try to make a redacted version that exhibits the problem as I understand how hard it would be to debug this otherwise. As the bug (high CPU usage when idle) takes an indeterminate amount of time to appear (1-60+minutes) it may take a few days before I can create & test this.


I don't know if it is related to the other bug I have regarding high-CPU usage when typing if graphics objects are Anchor: To Paragraph (rather than as character) https://bugs.documentfoundation.org/show_bug.cgi?id=120727
Comment 18 raroru 2019-02-21 21:36:19 UTC
Cross post with Bug 120727, as this look similar:

Hello,

i had the same problem as laurens with older version of Libreoffice, i uninstalled and reinstall last version and same problem again:

even only scrolling a simple document with text (and with the example of laurens as well in Bug 120727) is a nightmare: so slow.

Version: 6.2.0.3
Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62
CPU threads: 4; OS: Mac OS X 10.14.3; UI render: default; VCL: osx; 
Locale: fr-FR (en_FR.UTF-8); UI-Language: en-US
Calc: threaded

Computer:

  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro13,1
  Processor Name:	Intel Core i5
  Processor Speed:	2 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache (per Core):	256 KB
  L3 Cache:	4 MB
  Memory:	8 GB
  Boot ROM Version:	228.0.0.0.0
  SMC Version (system):	2.36f97




When scrolling, MAC OS activity monitor shows at least 60% use of CPU, up to more than 100% in a few seconds of scrolling.

Degrading to right click in libreoffice.app and"get info, low resolution" is better but still slow; and ugly.


Thanks for help!
Comment 19 raroru 2019-03-22 09:37:16 UTC
Hello,

still same problem with new version of Libreoffice

Version: 6.2.2.1
Build ID: fcd633fb1bf21b0a99c9acb3ad6e526437947b01
CPU threads: 4; OS: Mac OS X 10.14.3; UI render: default; VCL: osx; 
Locale: fr-FR (en_FR.UTF-8); UI-Language: en-US
Calc: threaded


The problem is happening with Libreoffice Impress /  presentation as well.


Thanks
Comment 20 Marqeaux 2019-05-08 15:55:35 UTC
I can confirm this behaviour. I just found it out when I was working on another computer while LibreOffice Writer was opened, but was idle. After a few minutes, the CPU went to 100%.

The document was a selfmade template of a package slip and had a OLE-object in it (Calc). I tried the same routine by leaving the computer in idle with a new LibreOffice Writer document, and in idle, LibreOffice behaved. I tried it again with a new, empty Writer document and added an empty OLE-object. And yes, after a few minutes the CPU went through the roof again.

I also checked of this behaviour was the same in Calc, but Calc itself didn't trigger the CPU. When in idle for a while, nothing happened.

Behaviour was on Xubuntu 18.04.2 on a 32-bits machine.
Comment 21 Marqeaux 2019-05-08 16:01:35 UTC
I forgot to mention to mention which version of LibreOffice I used. I used LibreOffice 6.2.2.2., Build-ID: 1:6.2.2.-0ubuntu0.18.04.1~lo1.
Comment 22 ross.stormcrow 2019-05-09 23:31:23 UTC
Created attachment 151278 [details]
Example file exhibiting behavior
Comment 23 ross.stormcrow 2019-05-09 23:43:04 UTC
This is an example file showing the 100% CPU utilization bug.  This will completely hang 6.0.x on Ubuntu for several minutes before it eventually displays.  Converting it using lowriter --convert-to to an ODT then opening it in an interactive session will hang 6.0.x indefinitely on a SandyBridge era Intel Core i5 2400S CPU.  Converting the same file to a PDF then viewing it takes a trivial amount of time (using lowriter --convert-to takes seconds to convert then display in a PDF viewer).  On a Dell laptop with an i5 8300H on Windows 10 with LO 6.2.3.2 AMD64 it still takes several minutes to display with the CPU pegged to 100%, but it will eventually do so and you can close it without hanging LO.
Comment 24 ross.stormcrow 2019-05-10 02:00:17 UTC
As a follow up to my last post, I upgraded my Kubuntu installation's LibreOffice to 6.2.3.2 (AMD64) from the LibreOffice.org packaged debs and opening that file with that version opened it normally without hanging at high utilization.  I have no idea why it's different between the Win 10 version and the Linux version on that particular file, but I'm seriously getting pissed with all the problems on Windows 10!

To be clearer:  the example .doc file seems to open fine in Kubuntu v 18.04.2 Linux but takes minutes in Windows 10 using the same version of LO 6.2.3.2 which seems stop responding with 100% utilization on one core.
Comment 25 Xisco Faulí 2019-05-16 10:17:06 UTC
Hello all,
this is a duplicate of bug 122207.
If you are suffering this problem, please use LibreOffice 6.1.6.3 or 6.2.3.2
Closing as RESOLVED DUPLICATED

*** This bug has been marked as a duplicate of bug 122207 ***
Comment 26 raroru 2019-05-18 17:05:47 UTC
Hello Xisco;

maybe i'm missing something but why resolved ?

in calc: 

i just tried with fresh install of

Version: 6.2.3.2
Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac
CPU threads: 4; OS: Mac OS X 10.14.4; UI render: default; VCL: osx; 
Locale: fr-FR (en_FR.UTF-8); UI-Language: en-US
Calc: threaded

with mac os  mojave 10.14.4 (18E226)
Model Name:	MacBook Pro
  Model Identifier:	MacBookPro13,1
  Processor Name:	Intel Core i5
  Processor Speed:	2 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache (per Core):	256 KB
  L3 Cache:	4 MB
  Memory:	8 GB
  Boot ROM Version:	231.0.0.0.0
  SMC Version (system):	2.36f97

and it still lags !

Only not satisfying solution is to check "open in low resolution"...

I will post in bug 122207 as well.
Comment 27 Xisco Faulí 2019-05-20 08:17:29 UTC

*** This bug has been marked as a duplicate of bug 122207 ***
Comment 28 laurens 2019-06-18 17:51:28 UTC
Hi - I don't know why this is marked as resolved or why it was marked as duplicate to another bug.

I'm still getting this 100% CPU usage after having work documents open for a while (with a lot of OLE objects).

The issue is sometimes temporarily resolved if I scroll up and down through the complete document. But after a few minutes the fans kick in again and LO is processing 100% whilst idly displaying my document.

Version: 6.2.4.2
Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
CPU threads: 12; OS: Mac OS X 10.14.5; UI render: default; VCL: osx; 
Locale: nb-NO (en_NO.UTF-8); UI-Language: en-US
Calc: threaded
Comment 29 Xisco Faulí 2019-08-08 09:29:30 UTC
I can't reproduce it in

Version: 6.4.0.0.alpha0+
Build ID: 6d024a69164716f7856ec936a72d01a6630d2a7c
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES-valencia (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

MAC only ?

What the behaviour in LibreOffice 6.3.0 to be released today?
Comment 30 laurens 2019-09-03 09:05:31 UTC
Still a dealbreaker for me in 6.3.1.2 :/ Using mainly macOS on a 2018 retina Macbook Pro. Note I deleted my user profile yesterday, so this is completely fresh, no extensions.

Just downloaded the latest LO RC (needed to get the trackpad reverse scrolling fix)

Version: 6.3.1.2
Build ID: b79626edf0065ac373bd1df5c28bd630b4424273
CPU threads: 12; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: nb-NO (en_NO.UTF-8); UI-Language: en-US
Calc: threaded

My work documents still jump to 100% CPU and eats my battery.
They contain graphics (anchor as character, because to Paragraph causes huge CPU usage and lag, see 120727). Also tried deleting Header and Footer, but that did not seem to change things. 

NOTE: CPU drops to 0% whilst one of the LO Pull Down menus is open.

I have a sample shot of the LibreOffice Process from Mac Activity Monitor - attaching a PNG that shows the calls that it seems to spend a LOT of CPU time in. I don't know if that helps anyone narrow it down?
Comment 31 laurens 2019-09-03 09:07:10 UTC
Created attachment 153833 [details]
Sample screenshot showing time in function calls when 100% CPU
Comment 32 laurens 2019-09-05 05:22:08 UTC
When the 100% core usage (In reply to laurens from comment #31)
> Created attachment 153833 [details]
> Sample screenshot showing time in function calls when 100% CPU

When the 100% usage occurs, then:

Tools -> Update -> Update All 

Seems to fix it for a while (View -> Web also prevents it from happening, but is not a solution for general use)
Comment 33 laurens 2019-10-08 07:54:52 UTC
Still a problem with 6.2.7.1
Version: 6.2.7.1
Build ID: 23edc44b61b830b7d749943e020e96f5a7df63bf
CPU threads: 12; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: nb-NO (en_NO.UTF-8); UI-Language: en-US

Still a temporary solution (for a few minutes) is:
Tools -> Update -> Update All 

I don't have a simple document to share that is not work related, but the https://bugs.documentfoundation.org/attachment.cgi?id=153833

shows what is eating up CPU cycles.

Anyone looking into this or any other way I can provide more useful information (apart from the screenshot and the temporary solution, which should help in figuring out where the problem lies)?