Download it now!
Bug 127235 - Layout loop in a specific document keeps adding pages indefinitely
Summary: Layout loop in a specific document keeps adding pages indefinitely
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.1.2 release
Hardware: All All
: medium normal
Assignee: Patrick Jaap
URL:
Whiteboard: target:6.4.0 target:6.3.3 target:6.2.8
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2019-08-30 07:48 UTC by Mike Kaganski
Modified: 2020-06-16 14:09 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Minimized sample with infinite layout loop adding pages (3.16 KB, application/vnd.oasis.opendocument.text)
2019-08-30 07:48 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2019-08-30 07:48:21 UTC
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/
Comment 1 Oliver Brinzing 2019-08-30 10:42:29 UTC
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:
Comment 2 Oliver Brinzing 2019-08-30 13:56:42 UTC
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 sha:7ed962571df02d1d7b286e7af534fadd717a8003
    source sha:7ed962571df02d1d7b286e7af534fadd717a8003

:040000 040000 4f196edc96f2b38e807f523d1f1c0039ea804f49 146fe4d7543a86109906b5c324666195bec234a1 M      instdir

/cygdrive/d/sources/bibisect/bibisect-win32-6.2
$ git bisect log
# bad: [35a87a66cfc6dfb661f6fed49fb32c081dd26bc7] source sha:d250c94d78ac7e79753aa30f869db919b01fc450
# good: [b0a56ec98b1368cb5e3e531e0b3f69565af91609] source sha:3a801799536e6870f2fb111b1cc00b9575a35a39

git bisect start 'master' 'oldest'
# good: [7f7b05d44d7d7f13cc9c865963a72e555b516b3d] source sha:1b88de0a07180661c4d5d6706247d546d06bc983
git bisect good 7f7b05d44d7d7f13cc9c865963a72e555b516b3d
# good: [1c3155d561cb094926cd19aa514856dfb4e23c5e] source sha:a626bdd56d7116efa57e65403ad51b56657148c3
git bisect good 1c3155d561cb094926cd19aa514856dfb4e23c5e
# good: [ae0a07b0d72f65d3de33abe942073e21270f85a8] source sha:1d3a07415eda3014d67d7c56466a8ad1d0ec51d9
git bisect good ae0a07b0d72f65d3de33abe942073e21270f85a8
# bad: [d08dc9d186b26aa58a919139e18d10f49382d6cb] source sha:0812325b46a877a6f150e5b9e1319e53eb9c87da
git bisect bad d08dc9d186b26aa58a919139e18d10f49382d6cb
# good: [544e385b8a4f068f227c67a2793ea644b9554ecf] source sha:78cc10e2615d06017a6a5700d464bc915395bd23
git bisect good 544e385b8a4f068f227c67a2793ea644b9554ecf
# good: [ffe09f940587f72f469267b0c9f2d83e9a4e1937] source sha:d09362e5c4a0bdd943fc3df7a20163eb13697b8b
git bisect good ffe09f940587f72f469267b0c9f2d83e9a4e1937
# good: [353467e8ac8001231ef4302d63cc21e2115dfd74] source sha:98b7cf194f012d06f569259c9379ac71f6cd565a
git bisect good 353467e8ac8001231ef4302d63cc21e2115dfd74
# bad: [028e34ed86238d129daa83618e842337c2c72bd6] source sha:08c98b7aba639e0d246f3662d7950885f8a81432
git bisect bad 028e34ed86238d129daa83618e842337c2c72bd6
# good: [1a4b3d008b7033ac5fd031fde09ef92676ac9394] source sha:650f3ee43c22a00c15799d31995b22fc8e0742c9
git bisect good 1a4b3d008b7033ac5fd031fde09ef92676ac9394
# good: [dbafe944e9bc78f2c3724f1731f2fb340497ecfb] source sha:ad32ff8f41e452156a2d16119b60542de11b42c8
git bisect good dbafe944e9bc78f2c3724f1731f2fb340497ecfb
# good: [28949153a189f72a24706cc8384c0bfda1f5e75b] source sha:04a6277f40727bf814c67a75e55ce3a6dcbc6bec
git bisect good 28949153a189f72a24706cc8384c0bfda1f5e75b
# bad: [9527da38080a89213fa4f49a267b5914f9975dfe] source sha:7ed962571df02d1d7b286e7af534fadd717a8003
git bisect bad 9527da38080a89213fa4f49a267b5914f9975dfe
# good: [df2a4eb5e038b03972f7823204aa0f90c9d3ef74] source sha:66f633086e2cf0c814df04627bff810d08e73329
git bisect good df2a4eb5e038b03972f7823204aa0f90c9d3ef74
# first bad commit: [9527da38080a89213fa4f49a267b5914f9975dfe] source sha:7ed962571df02d1d7b286e7af534fadd717a8003
Comment 3 Patrick Jaap 2019-08-30 14:22:35 UTC
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.
Comment 4 Patrick Jaap 2019-09-04 12:49:37 UTC
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?
Comment 5 Mike Kaganski 2019-09-04 13:13:36 UTC
(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?
Comment 6 Mike Kaganski 2019-09-04 13:23:18 UTC
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.
Comment 7 Patrick Jaap 2019-09-04 13:28:18 UTC
(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.
Comment 8 Patrick Jaap 2019-09-06 09:24:31 UTC
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/
Comment 9 Patrick Jaap 2019-09-06 09:25:42 UTC
Additional info: Why the graphic is so high is another question...
Comment 10 Commit Notification 2019-09-18 14:24:23 UTC
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.
Comment 11 Commit Notification 2019-09-19 09:39:57 UTC
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.
Comment 12 Timur 2019-09-19 12:03:13 UTC
No loop anymore. Patrick, please mark Fixed.
Comment 13 Xisco Faulí 2019-09-20 10:42:57 UTC
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!!
Comment 14 Commit Notification 2019-09-24 07:02:22 UTC
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.