https://bugs.documentfoundation.org/show_bug.cgi?id=170244
--- Comment #3 from Ján Gula <[email protected]> --- Created attachment 208054 --> https://bugs.documentfoundation.org/attachment.cgi?id=208054&action=edit Proposed fix: end SwTextFrame::Format_() loop on a stop request Still reproduces on master (27.2.0.0.alpha0, built from 7566e557de2c), and on 26.2.5.2. It is not a spin but unbounded allocation: ~500 MB/s until the OS kills the process, which is the "until crash" in the summary. Root cause. SwTextFormatter::NewPortion() sets Stop and returns no portion when it breaks at a fly anchored in a moved follow frame (the tdf#146500 rule). Nothing there changes the object's state, so every pass of the do/while in SwTextFrame::Format_() reaches the same decision. But Format_() exit for that case sits inside `if (!rInf.IsNewLine())`, and IsNewLine() is true on every pass, so this break is never evaluated even though both its conditions hold: if( rInf.IsStop() || rInf.GetIdx() >= nStrLen ) break; Each pass therefore appends another empty SwLineLayout and moves the frame down. On this document it is a 1-character paragraph growing for ever. Patch attached: check Stop before that guard, and drop it from the now redundant inner test. sw/source/core/text/frmform.cxx +9/-1, plus a test and a 17 KB reduction of attachment 204940 as test data (no fonts or images, they turned out not to be needed to reproduce). Applies to 7566e557de2c with `git am`. Verified, same commit and configure profile both ways: without it the document hangs and is OS-killed at 1.9 GB after 3.6 s, with it the document converts in 0.6 s. `make sw.check` is clean (172 test binaries). Four attachments from bugs 113425, 150768 and 55196 plus the gotenberg#1175 document all render identically patched vs unpatched, same page counts. Without the patch the new test hangs rather than fails, as tdf#38575 does. The bisect to ac5d5b4d looks correct -- IsShortCut() is on the stack, because this hang is during load in SwViewShell::ImplEndAction, not during export -- but I would not revert it: it made an existing non-convergence reachable rather than creating it, and reverting reinstates tdf#147666. I can post the per-pass trace of the loop and the full backtrace if useful. (I cannot reach gerrit.libreoffice.org:29418 from my network) -- You are receiving this mail because: You are the assignee for the bug.
