Bug 76219 - HANG i#84870: WW8: large objects in Russian text / DOC with complex header&footer / ... may cause loop (see comment 7 and 8)
Summary: HANG i#84870: WW8: large objects in Russian text / DOC with complex header&fo...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other All
: high major
Assignee: Not Assigned
URL: https://issues.apache.org/ooo/show_bu...
Keywords: filter:doc, perf
Depends on:
Blocks: Anchor-and-Text-Wrap Layout-Loops, Writer-Loops DOC-Opening
  Show dependency treegraph
Reported: 2014-03-16 00:40 UTC by Mike Kaganski
Modified: 2024-04-05 15:37 UTC (History)
23 users (show)

See Also:
Crash report or crash signature: ["objectpositioning::SwAnchoredObjectPosition::AdjustHoriRelPosForDrawAside(SwFrame const &,long,long,short,short,SvxLRSpaceItem const &,SvxULSpaceItem const &,bool)"]

bad .doc in ZIP archive (216 Kb) (216.92 KB, application/zip)
2014-03-16 00:40 UTC, Mike Kaganski
Minimal testcase (81.84 KB, application/x-zip-compressed)
2015-11-10 05:53 UTC, Mike Kaganski
Valgrind log of opening the minimal testcase (6.63 KB, text/plain)
2017-01-26 16:58 UTC, Buovjaga
Flamegraph (155.29 KB, application/x-bzip)
2019-12-22 14:18 UTC, Julien Nabet
bad .doc pages 53-54 (252.50 KB, application/msword)
2020-10-08 09:12 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2014-03-16 00:40:20 UTC
Created attachment 95878 [details]
bad .doc in ZIP archive (216 Kb)

This file hangs LO on opening.

i#84870 was filed for this problem, and was already fixed for AOO 3.4.1.

Citation from original issue:
> Oliver-Rainer Wittmann 2008-02-28 13:59:11 UTC
> investigations reveals the following:
> - it is not a crash, it is a layout loop
> - it is a regression - broken in OOo 2.0
> - the large as-character anchored graphic on page 67 causes the layout loop.

AOO 3.4.1, AOO 4.0.0 and AOO 4.0.1 all open the problematic file just fine.

The fix from AOO was taken and included in LO (http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5a8a2c3cbcee0175127a0662e3d820ea4deea22). So, it is considered fixed in LO.

It worked in (in, the file opened for a moment, but immediately crashed LO).

But starting with, the file hangs LO again (tested with LO,,,,, under Win7x64, and under Ubuntu 13.10 x64). So, regression -> priority high.

This fix is considered to cause Bug 47355 (see comments https://bugs.freedesktop.org/show_bug.cgi?id=47355#c56 by Michael Stahl and https://bugs.freedesktop.org/show_bug.cgi?id=47355#c65 by Björn Michaelsen).

Filing it here, to reflect its actual unfixed state.
Comment 1 Mike Kaganski 2014-03-16 00:52:09 UTC Comment hidden (obsolete)
Comment 2 Jean-Baptiste Faure 2014-03-16 09:11:04 UTC
Confirmed with dev. versions and master under Linux / Ubuntu 13.10 x86-64

Best regards. JBF
Comment 3 Michael Stahl (allotropia) 2014-03-18 10:41:22 UTC
loop in 3.5.3 is regression from:

commit 347bb1634b10eba577742fe8a7edb4b2dd69265d
Author:     Cédric Bosdonnat <cedric.bosdonnat.ooo@free.fr>
AuthorDate: Thu Mar 22 14:27:43 2012 +0100
Commit:     Caolán McNamara <caolanm@redhat.com>
CommitDate: Thu Mar 22 14:43:00 2012 +0000

    Revert "make text wrapping work in headers/footers too (fdo#39155)"
    This reverts commit e2a8fb0427e6b33a0fd3873bb7e077a6e5da8ebb. This is a
    feature, not a bug and would cause loads of documents to be badly

... which is indeed just a revert of a previous 3.5 commit.

so there is some _other_ commit here that causes this to loop
despite c5a8a2c3cbcee0175127a0662e3d820ea4deea22 and it's masked
during most of the 3.5 builds due to the above commit that was reverted.

... and of course it's probably not possible to bisect that because
of the "splitting the code over 20 git repos will magically make LO
modular" lunacy that was still going on during 3.5 cycle.
Comment 4 Joel Madero 2014-03-25 23:39:35 UTC
Still a problem for 4.3 built on Sun Mar 23 23:07:35 2014 +0100

Upping priority to Major since you just cannot open the document

adding bibisected - commit identified
Comment 5 Björn Michaelsen 2014-11-28 01:12:18 UTC
Just to clarify: c5a8a2c3cbcee0175127a0662e3d820ea4deea22 was never a valid fix for this, it caused the way more severe bug 47355. As such removing regression and bibisected keywords and marking this as "inherited from OOo" as without c5a8a2c3cbcee0175127a0662e3d820ea4deea22 OOo was broken as well.
Comment 7 Mike Kaganski 2015-11-10 05:53:19 UTC
Created attachment 120433 [details]
Minimal testcase

The original analysis in i#84870 seems to be a somewhat incorrect:

The problem is caused not by object on page 67, but by two objects on pages 53 and 54, their headers having floating frame with page numbering.

The attached document only contain two large objects (black rectangles), each anchored as character, and the header, the minimal combination that cause the loop. Also PDF produced by MS Word is included.
Comment 8 Mike Kaganski 2015-11-10 11:20:26 UTC
The loop is in
void SwLayAction::InternalAction(OutputDevice* pRenderContext)

Entering the loop
while ( (pPage && !IsInterrupt()) || nCheckPageNum != USHRT_MAX )
it never reaches exit conditions;
in the loop, it endlessly adds next pages in FormatContent( pPage ).
This must eventually lead to OOM.
Comment 9 Xisco Faulí 2017-01-26 11:22:14 UTC
Freeze still reproducible in

Build ID: d3ff66999d924e832f8219c65ced0526f1a67f82
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 10 Xisco Faulí 2017-01-26 12:09:29 UTC
*** Bug 64991 has been marked as a duplicate of this bug. ***
Comment 11 Xisco Faulí 2017-01-26 15:58:21 UTC
*** Bug 57980 has been marked as a duplicate of this bug. ***
Comment 12 Xisco Faulí 2017-01-26 16:01:41 UTC
*** Bug 42603 has been marked as a duplicate of this bug. ***
Comment 13 Xisco Faulí 2017-01-26 16:06:23 UTC
*** Bug 37146 has been marked as a duplicate of this bug. ***
Comment 14 Xisco Faulí 2017-01-26 16:16:34 UTC
*** Bug 55196 has been marked as a duplicate of this bug. ***
Comment 15 Xisco Faulí 2017-01-26 16:54:34 UTC
*** Bug 99274 has been marked as a duplicate of this bug. ***
Comment 16 Xisco Faulí 2017-01-26 16:57:43 UTC
*** Bug 61967 has been marked as a duplicate of this bug. ***
Comment 17 Buovjaga 2017-01-26 16:58:50 UTC
Created attachment 130707 [details]
Valgrind log of opening the minimal testcase

Arch Linux 64-bit, KDE Plasma 5
Build ID: 63fd4c97118a943c84ba5a666cf8c9cc54b511c7
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on January 22th 2016
Built with --enable-symbols
Comment 18 Xisco Faulí 2017-01-26 17:02:35 UTC
*** Bug 65881 has been marked as a duplicate of this bug. ***
Comment 19 Xisco Faulí 2017-01-26 18:03:58 UTC
*** Bug 64997 has been marked as a duplicate of this bug. ***
Comment 20 Xisco Faulí 2017-01-26 18:20:25 UTC
*** Bug 60501 has been marked as a duplicate of this bug. ***
Comment 21 Xisco Faulí 2017-01-26 18:25:02 UTC
I've been able to find 10 dupes of this bugs ( probably there are more in Bugzilla).
@Mike, Do you feel like fixing this one?
Comment 22 Mike Kaganski 2017-01-29 19:17:20 UTC
(In reply to Xisco Faulí from comment #21)

Unfortunately, that's not that straightforward.
A document with layout problem that starts opening after some layout processing change doesn't necessarily mean that the change has fixed this document's problem. It may be just that this change has only moved the problematic point, say, away from page break towards middle of a page (where it doesn't cause infinite loop). And the problem is still there, but doesn't show itself.

I don't claim that all these bugs aren't duplicates; but I just wanted to say that I wouldn't be surprised if there are two or three different problems here.
Comment 23 Lior Kaplan 2017-11-04 09:08:21 UTC Comment hidden (obsolete)
Comment 24 Timur 2018-12-27 17:02:38 UTC Comment hidden (obsolete)
Comment 25 Julien Nabet 2019-12-22 14:18:35 UTC
Created attachment 156731 [details]

Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today (gtk3 rendering + enable-symbols)

If needed for testing, I can apply some patch locally and provide a Flamegraph, Valgrind, bt (or 3!) of course, not 10 times a day :-).
Comment 26 Xisco Faulí 2020-01-14 12:24:19 UTC Comment hidden (obsolete)
Comment 27 Telesto 2020-05-26 18:06:54 UTC
(In reply to Xisco Faulí from comment #26)
> @Noel, I thought you might be interested in this issue...

Another anchoring issues..
Comment 28 Timur 2020-10-08 09:12:51 UTC
Created attachment 166176 [details]
bad .doc pages 53-54

My observations here:
- original attachment 95878 [details] 90-pages DOC still freezes LO 7.1+
- MSO saved DOCX opens 89-pages in LO 7.1+ (presumably OK with Microsoft fonts)
- attachment 120433 [details] 2-page DOC opens 2 pages in LO 7.1+
- here is MSO reduced original DOC to pages 53-54, which in Comment 7 were explained to case the loop
- duplicates are questionable, only can be confirmed if this one is fixed.
Comment 29 Timur 2021-06-09 13:55:15 UTC
Resolved in 7.2+ with fix from Daniel. So I mark duplicate of another DOC.

commit ba698a8561700f503cdd7a5cb0bc83d6eaf4222b
Date:   Fri May 21 08:16:39 2021 +0200
    source 798b69087119c01a3b51e0bb3240ef35cfededeb
    previous fb5247bf587518eaa01cf5d54dceddf73827d740
author	Daniel Arato (NISZ) <arato.daniel@nisz.hu>	2021-03-24 20:18:16 +0100
committer	László Németh <nemeth@numbertext.org>	2021-05-21 08:00:33 +0200
commit 798b69087119c01a3b51e0bb3240ef35cfededeb (patch)

*** This bug has been marked as a duplicate of bug 96840 ***
Comment 30 Aron Budea 2021-08-23 01:02:30 UTC
Since that commit has been reverted, let's set this back to NEW. We can't know if another fix there will fix this for sure.
Comment 31 QA Administrators 2023-11-10 03:14:02 UTC Comment hidden (obsolete)
Comment 32 t.schaaf 2023-11-15 18:10:26 UTC Comment hidden (obsolete)
Comment 33 Buovjaga 2023-11-16 06:15:43 UTC
Testing with the .doc in attachment 120433 [details], it opens with oldest of 7.5 Win bibisect repo, but closing it hangs. With 7.6.2 it works fine. Let's close as WFM.
Comment 34 Timur 2023-11-16 12:43:45 UTC
For original  attachment 95878 [details] and attachment 166176 [details] bad .doc pages 53-54.
Opeing fixed in 7.6:
commit 3b90e991443cbdafbee64de91e4f068633b80350
Date:   Sun Oct 29 16:47:17 2023 +0100
    source 4f91e6c91b449ffe1e51cc517e8fc93179feca67
author	Justin Luth <jluth@mail.com>	Thu May 25 12:19:16 2023 -0400
tdf#133504 doc import: set the correct wrap