Bug 141556 - Ongoing 100% CPU usage after opening document
Summary: Ongoing 100% CPU usage after opening document
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2 all versions
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Luke Deller
URL:
Whiteboard: target:7.2.0 target:7.1.4
Keywords: bibisected, bisected, perf, regression
Depends on:
Blocks: Main-Loop
  Show dependency treegraph
 
Reported: 2021-04-08 08:29 UTC by Luke Deller
Modified: 2021-05-03 10:27 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Bug document (93.86 KB, application/vnd.oasis.opendocument.text)
2021-04-08 08:31 UTC, Luke Deller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Deller 2021-04-08 08:29:48 UTC
Description:
When I open the attached text document in LibreOffice, its CPU usage is stuck at 100% (one CPU core).  This only stops if I scroll the document to page 15.

Steps to Reproduce:
1. Open attached document
2. Observe LibreOffice CPU usage

Actual Results:
CPU usage remains at 100% (of one CPU core) indefinitely - unless the document is scrolled to page 15

Expected Results:
CPU usage should drop to near 0% after a while when nothing is being done in the UI


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Tested in LibreOffice 6.0.1.1 and in latest master built from source (both on Ubuntu 20.04) - same result.

Breaking in the debugger shows that SwLayAction::FormatContent is being called repeatedly for page 15.
Comment 1 Luke Deller 2021-04-08 08:31:14 UTC
Created attachment 171025 [details]
Bug document
Comment 2 Xisco Faulí 2021-04-08 08:56:33 UTC
Reproduced in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: 78eaf6489a6542378ffab7eef39ec0a2c5f1a10a
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 3 Xisco Faulí 2021-04-08 09:14:09 UTC
The issue started to happen after

https://cgit.freedesktop.org/libreoffice/core/commit/?id=b4b5dbee1ec7770ed64d7270de46d5cfc06b87b6

author	Miklos Vajna <vmiklos@collabora.co.uk>	2016-03-23 16:44:43 +0100
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2016-03-23 16:36:48 +0000
commit	b4b5dbee1ec7770ed64d7270de46d5cfc06b87b6 (patch)
tree	861f662a721df5bd3f6a2569db0d3ae49864972f
parent	11231f9179db9821effc884e8adade48fdf89938 (diff)
tdf#88453 sw layout: fix split of nested tables with large amount of rows

Bisected with: bibisect-linux-64-5.2

Adding Cc: to Miklos Vajna
Comment 4 Luke Deller 2021-04-09 02:18:24 UTC
I believe what is happening here is the idle layout processing keeps getting interrupted on page 15.  Each time it is invoked, it resumes from page 15 but does not progress far enough before being interrupted again, so next time it resumes back at the same point - so it never finishes.

There was a stopwatch timer introduced in commit 383032c50a3e3354f04200ce984a47ab9d2c5c67 for tdf#123583, which interrupts idle processing every 50 milliseconds.  To test my explanation of the problem, I tried extending this timer to 60 seconds, and that does indeed fix the problem - but this is not the right fix because the application is unresponsive for too long when the document is opened because the idle task is not being interrupted at all.

Instead I tried reverting commit 383032c50a3e3354f04200ce984a47ab9d2c5c67, which brings us back to the previous behaviour where idle processing is only interrupted if there is some input event.  In theory this sounds great, but I saw that the idle processing was still being interrupted many times per second causing the same symptoms.  Debugging with gdb, I saw this was a TIMER event.

This is very similar to problems addressed previously in commit b4f35a7450830979b937ec6ae3b6d638302093d2 (2015) and commit 6160127ba9b03b991736e0157c2d134795fa196f (2005), which filter out TIMER events so that they will not interrupt idle processing - but these commits missed one spot!  This line:
https://git.libreoffice.org/core/+/refs/changes/90/18590/2/sw/source/core/layout/layact.cxx/#2168

When I apply a similar change onto this line, the present bug is fixed for me: CPU usage is high for about 12 seconds then drops to zero.  Also this (re-)fixes tdf#123583
Comment 5 Luke Deller 2021-04-09 02:33:08 UTC
Proposed patch here:
https://gerrit.libreoffice.org/c/core/+/113825
Comment 6 Telesto 2021-04-09 08:10:08 UTC
(In reply to Luke Deller from comment #4)
> I believe what is happening here is the idle layout processing keeps getting
> interrupted on page 15.  Each time it is invoked, it resumes from page 15
> but does not progress far enough before being interrupted again, so next
> time it resumes back at the same point - so it never finishes.
> 
> There was a stopwatch timer introduced in commit
> 383032c50a3e3354f04200ce984a47ab9d2c5c67 for tdf#123583, which interrupts
> idle processing every 50 milliseconds.  To test my explanation of the
> problem, I tried extending this timer to 60 seconds, and that does indeed
> fix the problem - but this is not the right fix because the application is
> unresponsive for too long when the document is opened because the idle task
> is not being interrupted at all.

Thanks for the nice investigation. I believe there where few more overlooked area's (or everything comes down to single issue here). I bundled them here: bug 119334 (most reports are by me). I haven't re-checked them, so blindly estimating those still being present. 

Will re-check after you're patch is in.

If those are still present after this, may I add you to the CC?  I hope you might be interested to repeat the trick :P. For the sake of the environment (wasting CPU time/ power on loops). And battery life. Obviously voluntary, no pressure at all.
Comment 7 Commit Notification 2021-04-14 06:26:14 UTC
Luke Deller committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0fedac18214a6025401c4c426466a5166553e8ec

tdf#141556 Fix 100% CPU usage in Writer idle loop

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Xisco Faulí 2021-04-14 18:10:12 UTC
Verified in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: a199e4ea389c934d169a178433f4b94033e60f93
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Luke, thanks for fixing this issue!!
Comment 9 Commit Notification 2021-05-03 10:27:56 UTC
Luke Deller committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/b33148071ae6256845352f8625e58b1ab95be41c

tdf#141556 Fix 100% CPU usage in Writer idle loop

It will be available in 7.1.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.