Description: 45 seconds processing when adding 5 pages to large 817 pag doc with 4000 footnotes (SwFootnoteBossFrame::CollectFootnotes_ Steps to Reproduce: 1. Open the attached file (source: bug 130822) 2. Press CTRL+Enter 5x notice 45 seconds of CPU processing Actual Results: 45 seconds of background processing Expected Results: Somewhat more resource friendly? Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.1.0.0.alpha0+ (x86) Build ID: 9af38b4504ccda57a0c32eb8bdd03e5a8ca29ddc CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL not in 4.4.7.2 (or at least not in this way) Idle stuff (as bibisected before)
Created attachment 162764 [details] Example file
Created attachment 162765 [details] BT with symbols VTune Profiler based on x39 build
*** Bug 134081 has been marked as a duplicate of this bug. ***
Created attachment 162772 [details] Example file Another example 1. Open the attached file 2. Insert -> Table of content -> Table of contents 3. Press OK and start waiting (can take 2 minutes or so) 4. If you like waiting.. press CTRL+Z 5. Press CTRL+Y -> RuleBasedBreakIterator + Footnotes Of course as nice idle process.. so you can keep editing..
Another way 1. Open the attached file 2. CTRL+A (3x) 3. CTRL+X 4. CTRL+Z -> should cause SwFlyFrame::ResetNotifyBack swlo [unknown] 0 0x7ffeca048aed SwFlyFrame::ResetNotifyBack swlo [unknown] 0 0x7ffeca048719 SwLayoutFrame::MoveLowerFootnotes swlo [unknown] 0 0x7ffeca04c051 5. Update index to get a proper page count -> could cause it again
Created attachment 166907 [details] Example file
Please see if affected by fix in bug 76260.
No improvement Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: f96004096268f5e71120678e32fc8c74055819aa CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
I actually think it god worse, it loops now @NISZ They hope was commit 9b39ce0e66acfe812e1d50e530dc2ccdef3e1357 making a difference here (opening is fine, but the reported issue is still present). However I think it got worse since my report (it really doesn't stop.. or taking very long time). Many possibility's why (Bjoern (SwModify::~SwModify), Lubos (font buffering), Stahl (layout loop control), László (Improving footnotes). C++ EH exception - code e06d7363 is done over and over (but no clue what it means) Once a while warnings come along: warn:sw.core:5448:3544:sw/source/core/docnode/node.cxx:1980: Wrong cond collection, skipping check of Cond Colls. warn:legacy.osl:5448:3544:sw/source/core/layout/flowfrm.cxx:2561: <SwFlowFrame::MoveBwd(..)> - layout loop control for layout action <Move Backward> applie warn:legacy.osl:5448:3544:sw/source/core/layout/ftnfrm.cxx:1873: _CollectFootnote: Master expected It does work 'perfectly' fine as background process (so typing and such is smooth), but this is surely a battery drain :P. Seeing 100% CPU usage (single core) for 4 minutes.. (it doesn't look like a timer glitch to me)
Repro with attachment 162764 [details]. Tested with Linux 7.4 bibisect repo. It indeed seems to be the idle rework. I tested with Linux 50max repo and in source commit 01f406bc28f53acc5a2734af637aa8074a5d1813 it does not hit the CPU like it hits after the bibisect commit containing multiple ones (including the idle rework). I couldn't run the bibisect commit with the range of commits, but this source commit showed the problems: 01f406bc28f53acc5a2734af637aa8074a5d1813 Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: cfd82e7a2cc2b45b738eb0efa0827196d2de61a4 CPU threads: 8; OS: Linux 5.16; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug