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.
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.
This is a regression, bibisect...
Bisected using the bisect-linux-64-6.3 repo: # bad: [5ab18ef32ff04ddc8308a892a08859b635c39294] source 8e3afdb5989d571410350f1d43fcf26492a4eaff git bisect bad 5ab18ef32ff04ddc8308a892a08859b635c39294 # good: [b88246fce459aa38f28c0bd3cde05afd0b694a7d] source 8a7a93b3f24b95bfcffc25e58f9e43c7be4cc1f1 git bisect good b88246fce459aa38f28c0bd3cde05afd0b694a7d # first bad commit: [5ab18ef32ff04ddc8308a892a08859b635c39294] source 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?
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! ...
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
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.
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.
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.
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.
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 :)
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.
Hi, the issue is fixed in LibreOffice 7.0. Best, Patrick
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!
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.
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.