Created attachment 153744 [details] Minimized sample with infinite layout loop adding pages Opening attachment with Version: 6.3.1.1 (x64) Build ID: e979878b49a48dab15ebe528f238b88125e32c65 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded (and reportedly 6.2.5.2), pages count in the statusbar keep increasing indefinitely. But not in Version: 6.1.5.2 (x64) Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 CPU threads: 12; OS: Windows 10.0; UI render: GL; Locale: en-US (ru_RU); Calc: group threaded Note: removing <text:soft-page-break /> from content.xml makes LibreOffice hang on opening. See https://ask.libreoffice.org/en/question/206624/writer-all-of-a-sudden-starts-adding-many-thousands-of-new-pages/
reproducible with: Version: 6.2.6.2 (x64) Build-ID: 684e730861356e74889dfe6dbddd3562aae2e6ad CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: Version: 6.3.1.1 (x64) Build-ID: e979878b49a48dab15ebe528f238b88125e32c65 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: Version: 6.4.0.0.alpha0+ (x64) Build ID: 1c7fdf561bc924741a121439a6cb42f96f285b58 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded but *not* with: Version: 6.1.7.2 (x64) Build-ID: 22 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc:
seems to have started with: https://gerrit.libreoffice.org/plugins/gitiles/core/+/7ed962571df02d1d7b286e7af534fadd717a8003 commit 7ed962571df02d1d7b286e7af534fadd717a8003 [log] author Patrick Jaap <patrick.jaap@tu-dresden.de> Wed Jan 23 10:01:36 2019 +0100 committer Miklos Vajna <vmiklos@collabora.com> Mon Feb 11 18:08:41 2019 +0100 tree a7eec19f106b3a3a1c589311ed8516fc1c5a558c parent 66f633086e2cf0c814df04627bff810d08e73329 [diff] tdf#122878: enable wrap for flys in footer This patch removes the check for a footer node, intoduced by 23f698ecee033612ac3a9f5cfd7674b08bb3ccd1 preserving the behaviour for the connected bug reports i13832 and i24135. Without this check, the wraping becomes enabled for footer objects, too. With this enhencement, the commits 7df33caac85ac90c26e97dedbc201f46dc9e4cb4 d3db6ff43a531ecf1afc858a0a8832353d091644 are directly affected and therefore the unit test is edited. /cygdrive/d/sources/bibisect/bibisect-win32-6.2 $ git bisect good 9527da38080a89213fa4f49a267b5914f9975dfe is the first bad commit commit 9527da38080a89213fa4f49a267b5914f9975dfe Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Mon Feb 11 09:18:32 2019 -0800 source 7ed962571df02d1d7b286e7af534fadd717a8003 source 7ed962571df02d1d7b286e7af534fadd717a8003 :040000 040000 4f196edc96f2b38e807f523d1f1c0039ea804f49 146fe4d7543a86109906b5c324666195bec234a1 M instdir /cygdrive/d/sources/bibisect/bibisect-win32-6.2 $ git bisect log # bad: [35a87a66cfc6dfb661f6fed49fb32c081dd26bc7] source d250c94d78ac7e79753aa30f869db919b01fc450 # good: [b0a56ec98b1368cb5e3e531e0b3f69565af91609] source 3a801799536e6870f2fb111b1cc00b9575a35a39 git bisect start 'master' 'oldest' # good: [7f7b05d44d7d7f13cc9c865963a72e555b516b3d] source 1b88de0a07180661c4d5d6706247d546d06bc983 git bisect good 7f7b05d44d7d7f13cc9c865963a72e555b516b3d # good: [1c3155d561cb094926cd19aa514856dfb4e23c5e] source a626bdd56d7116efa57e65403ad51b56657148c3 git bisect good 1c3155d561cb094926cd19aa514856dfb4e23c5e # good: [ae0a07b0d72f65d3de33abe942073e21270f85a8] source 1d3a07415eda3014d67d7c56466a8ad1d0ec51d9 git bisect good ae0a07b0d72f65d3de33abe942073e21270f85a8 # bad: [d08dc9d186b26aa58a919139e18d10f49382d6cb] source 0812325b46a877a6f150e5b9e1319e53eb9c87da git bisect bad d08dc9d186b26aa58a919139e18d10f49382d6cb # good: [544e385b8a4f068f227c67a2793ea644b9554ecf] source 78cc10e2615d06017a6a5700d464bc915395bd23 git bisect good 544e385b8a4f068f227c67a2793ea644b9554ecf # good: [ffe09f940587f72f469267b0c9f2d83e9a4e1937] source d09362e5c4a0bdd943fc3df7a20163eb13697b8b git bisect good ffe09f940587f72f469267b0c9f2d83e9a4e1937 # good: [353467e8ac8001231ef4302d63cc21e2115dfd74] source 98b7cf194f012d06f569259c9379ac71f6cd565a git bisect good 353467e8ac8001231ef4302d63cc21e2115dfd74 # bad: [028e34ed86238d129daa83618e842337c2c72bd6] source 08c98b7aba639e0d246f3662d7950885f8a81432 git bisect bad 028e34ed86238d129daa83618e842337c2c72bd6 # good: [1a4b3d008b7033ac5fd031fde09ef92676ac9394] source 650f3ee43c22a00c15799d31995b22fc8e0742c9 git bisect good 1a4b3d008b7033ac5fd031fde09ef92676ac9394 # good: [dbafe944e9bc78f2c3724f1731f2fb340497ecfb] source ad32ff8f41e452156a2d16119b60542de11b42c8 git bisect good dbafe944e9bc78f2c3724f1731f2fb340497ecfb # good: [28949153a189f72a24706cc8384c0bfda1f5e75b] source 04a6277f40727bf814c67a75e55ce3a6dcbc6bec git bisect good 28949153a189f72a24706cc8384c0bfda1f5e75b # bad: [9527da38080a89213fa4f49a267b5914f9975dfe] source 7ed962571df02d1d7b286e7af534fadd717a8003 git bisect bad 9527da38080a89213fa4f49a267b5914f9975dfe # good: [df2a4eb5e038b03972f7823204aa0f90c9d3ef74] source 66f633086e2cf0c814df04627bff810d08e73329 git bisect good df2a4eb5e038b03972f7823204aa0f90c9d3ef74 # first bad commit: [9527da38080a89213fa4f49a267b5914f9975dfe] source 7ed962571df02d1d7b286e7af534fadd717a8003
Hi! I can reproduce the problem in new LO versions and think it is indeed related to my commit. I'll take a look, thanks for the minimal file.
Ok, the bug is not directly caused by my commit, it just shows up now. The reason is the wrong layout of the graphic. Before my commit: The graphic is too wide for the first page and therefore placed on the second page (I think this behaviour is wrong and a bug). After my commit: When it is now placed on the second page it seems to intersect with fly frame in the footer (the page number). This causes the graphic to get out of the way of the page number an therefore it is placed on the third page. There another footer is created and this causes the infinite loop. My observations: If I reduce the width (NOT the height) of the graphic a bit, everything fine both before and after my commit (and there is only one page). Can someone agree that the placement on the second page is not the right behaviour if the graphic is too wide?
(In reply to Patrick Jaap from comment #4) There might be an image placement bug here - but based on your description, we can also get an infinite loop if the first page would get such footer - even without that bug?
IMO the move to the second page is correct here: the frame is anchored as character; it is preceded with a space, and so the too-wide "character" is naturally wrapped to the next line (and moves to the next page). Normally now the new line would start with that object (not with a space), and thus no wrap would happen again.
(In reply to Mike Kaganski from comment #6) Thanks for the info. Makes sense to me. Then I think we need (another) corner case in SwTextFly::GetTop(). Layout is always such a fragile thing. I'll keep investigating.
I found something: https://gerrit.libreoffice.org/#/c/78696/ But I need a second opinion. The graphic in the attached document has a frame of >30000 twpis is height and cannot fit on any page. Therefore, I cought that case. Seems not to break any tests and resolves the issue from https://ask.libreoffice.org/en/question/206624/writer-all-of-a-sudden-starts-adding-many-thousands-of-new-pages/
Additional info: Why the graphic is so high is another question...
Patrick Jaap committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/37b79c872b2637912c5d6972812ee2c9d5b096c7 WIP: tdf#127235 break if object is larger than page It will be available in 6.4.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.
Patrick Jaap committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/154a9fc26890a34ac885f3191bf339b758c97936 tdf#127235 break if object is larger than page It will be available in 6.3.3. 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.
No loop anymore. Patrick, please mark Fixed.
Verified in Version: 6.4.0.0.alpha0+ Build ID: ea4f3099d6e0cf30d80caa8b2121c7a358f80fdd CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Patrick Jaap, thanks for fixing this issue!!
Patrick Jaap committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/commit/1e9d08d046bfe362e5e2ffeb36e35692fc3b55f5 tdf#127235 break if object is larger than page It will be available in 6.2.8. 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.