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.
Created attachment 171025 [details] Bug document
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
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
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
Proposed patch here: https://gerrit.libreoffice.org/c/core/+/113825
(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.
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.
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!!
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.