Bug 130262 - Writer thinks a two page doc file has an infinite number of pages
Summary: Writer thinks a two page doc file has an infinite number of pages
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
6.3.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0 target:6.4.2 target:6.3.6
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2020-01-29 16:56 UTC by andres@verot.com
Modified: 2020-02-11 16:19 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
File that causes the problem to trigger (127.00 KB, application/msword)
2020-01-29 16:56 UTC, andres@verot.com
Details
sal_warning.txt (71.78 KB, text/plain)
2020-01-30 13:19 UTC, Kevin Suo
Details
Minimal file (36.00 KB, application/msword)
2020-01-30 18:25 UTC, Patrick Jaap
Details

Note You need to log in before you can comment on or make changes to this bug.
Description andres@verot.com 2020-01-29 16:56:06 UTC
Created attachment 157503 [details]
File that causes the problem to trigger

When I open the file I attached to the report, Write starts an infinite loop in which the number of pages counters keeps increasing until I force the program to close.

I have only tested in Windows.
Comment 1 ian 2020-01-30 03:19:24 UTC
Thank you for reporting the bug. I can confirm that the bug is present in the previous LibreOffice release.

Version: 6.3.4.2 (x64)
Build ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa
CPU threads: 2; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

It may have existed in earlier versions as well.
Comment 2 Kevin Suo 2020-01-30 12:40:42 UTC
This is a regression, bibisect...
Comment 3 Kevin Suo 2020-01-30 13:01:56 UTC
Bisected using the bisect-linux-64-6.3 repo:

# bad: [5ab18ef32ff04ddc8308a892a08859b635c39294] source sha:8e3afdb5989d571410350f1d43fcf26492a4eaff
git bisect bad 5ab18ef32ff04ddc8308a892a08859b635c39294
# good: [b88246fce459aa38f28c0bd3cde05afd0b694a7d] source sha:8a7a93b3f24b95bfcffc25e58f9e43c7be4cc1f1
git bisect good b88246fce459aa38f28c0bd3cde05afd0b694a7d
# first bad commit: [5ab18ef32ff04ddc8308a892a08859b635c39294] source sha:8e3afdb5989d571410350f1d43fcf26492a4eaff

commit 8e3afdb5989d571410350f1d43fcf26492a4eaff
Author: Patrick Jaap <patrick.jaap@tu-dresden.de>
Date:   Wed Jan 23 10:01:36 2019 +0100

    tdf#122878: enable wrap for flys in footer

Adding cc @Patrick: Would you please take a look?
Comment 4 Kevin Suo 2020-01-30 13:19:10 UTC
Created attachment 157529 [details]
sal_warning.txt

I noticed the attached related SAL_WARNings which may be useful. 

warn:legacy.osl:592144:592144:sw/source/core/layout/layact.cxx:544: LoopControl_1 in SwLayAction::InternalAction
...
warn:sw.a11y:592144:592144:sw/source/core/access/acctable.cxx:1232: table has invalid position
warn:sw.a11y:592144:592144:sw/source/core/access/acctable.cxx:1232: table has invalid position
warn:legacy.osl:592144:592144:sw/source/core/access/acccontext.cxx:446: fire event for disposed frame?
...
warn:legacy.osl:592144:592144:sw/source/core/crsr/crsrsh.cxx:1948: endless loop? CharRect != OldCharRect 
...
warn:sw.core:592144:592144:sw/source/core/view/vdraw.cxx:243: Trying to move anchor from invalid page - fix layouting!
...
Comment 5 Patrick Jaap 2020-01-30 15:08:48 UTC
Hi,

looks exactly like the docx regression tdf#127235.

Maybe I can apply the same patch to the doc filter!

I'll take a look
Comment 6 Patrick Jaap 2020-01-30 18:25:27 UTC
Created attachment 157545 [details]
Minimal file

I stripped the file down:

There is only one drawing line in the footer and one small floating table in the body. I think this narrows the problem down.

Somehow the line thinks it is intersecting with the table and therefore, wants to place the table on the next page => this creates a new footer with a new line and the endless loop starts.

Converting to docx does not trigger the problem.
Comment 7 Patrick Jaap 2020-02-03 07:45:51 UTC
I did some research:

The layout code thinks the table is overlapping with the small line in the footer. In the doc model dump I found the property

<SvxULSpaceItem whichId="92" nUpper="13520" nLower="13520" bContext="false" nPropUpper="100" nPropLower="100"/>

of the line. This looks pretty wrong, since the is a half page (13500 twips) upper and lower space reserved for the line. Therefore layout code thinks the line covers the whole page. 

My problem is that I'm not familiar with doc-import filter. I am not sure where and why this wrong space item is set. I will ask in the mailing list.
Comment 8 Miklos Vajna 2020-02-05 08:38:23 UTC
A couple of pointers:

- The DOC import starts in WW8Reader::Read, put a breakpoint there before you enable other breakpoints, so you don't get noise from soffice startup.

- The upper/lower spacing is read in SwWW8ImplReader::Read_UL(), the first thing I would check if nPara there is ever indeed that large 13520 value.

- If not, you could put a breakpoint on SvxULSpaceItem::SvxULSpaceItem() and see if anybody creates such a pool item with the 13520 value.

Hopefully one of these will tell you the source of the 13520 value.
Comment 9 Patrick Jaap 2020-02-05 17:43:38 UTC
Thanks!

The bad value is put in sw/source/filter/ww8/ww8graf.cxx:1987

where pRecord->nDyWrapDistTop = 6763728

-> Since the nUpper value of the SvxULSpaceItem is 16 bit, we get an overflow here! Next step is to find the origin of the pRecord->nDyWrapDistTop value.

I'll stay on it.
Comment 10 Patrick Jaap 2020-02-06 17:49:29 UTC
Hi!

Patch on Gerrit: https://gerrit.libreoffice.org/c/core/+/88127

The cause of the problem are signed values in the binary doc format which are read as unsigned and causes wrong numbers. This current patch is resolving the bug by ignoring negative values but it is way to strict, since there are cases where negative values are needed.

I need some advice how to narrow down these cases. But I think got the worst part done :)
Comment 11 Commit Notification 2020-02-10 08:36:09 UTC
Patrick Jaap committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8cbd7f59bb99282c4bcb60639da1263c8eb3a5e3

tdf#130262 ignore negative wrap distance values in doc prop import

It will be available in 7.0.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 12 Patrick Jaap 2020-02-10 09:35:15 UTC
Hi, the issue is fixed in LibreOffice 7.0. 

Best,
Patrick
Comment 13 Xisco Faulí 2020-02-11 12:42:49 UTC
Verified in

Version: 7.0.0.0.alpha0+
Build ID: 5d00a1c9c6e85f3d7a3e05ab485da79980c38d44
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

@Patrick, thanks for fixing this issue!
Comment 14 Commit Notification 2020-02-11 14:31:05 UTC
Patrick Jaap committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/6e5444959ec914f6d0979aa1e6d4d8a462d79891

tdf#130262 ignore negative wrap distance values in doc prop import

It will be available in 6.4.2.

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 15 Commit Notification 2020-02-11 16:19:15 UTC
Patrick Jaap committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/commit/82288db9bbc69892408ebccb96091d03b2d0dabb

tdf#130262 ignore negative wrap distance values in doc prop import

It will be available in 6.3.6.

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.