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 3.5.2.2 (in 3.5.0.3, 3.5.1.2 the file opened for a moment, but immediately crashed LO). But starting with 3.5.3.1, the file hangs LO again (tested with LO 3.5.3.1, 3.5.7.2, 3.6.7.2, 4.0.6.1, 4.1.5.3, 4.2.3.1 under Win7x64, and 4.2.2.1 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.
(Sorry, I made the issue NEW from the start by mistake - making it UNCONFIRMED)
Confirmed with dev. versions 4.2.4.0.0+ and master under Linux / Ubuntu 13.10 x86-64 Best regards. JBF
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 rendered. ... 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.
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
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.
see also: http://cgit.freedesktop.org/libreoffice/core/commit/?id=a54da6a84f751250c694120d1a29aaac89cd3af4&h=libreoffice-4-2
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.
The loop is in void SwLayAction::InternalAction(OutputDevice* pRenderContext) (sw/source/core/layout/layact.cxx) 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.
Freeze still reproducible in Version: 5.4.0.0.alpha0+ 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
*** Bug 64991 has been marked as a duplicate of this bug. ***
*** Bug 57980 has been marked as a duplicate of this bug. ***
*** Bug 42603 has been marked as a duplicate of this bug. ***
*** Bug 37146 has been marked as a duplicate of this bug. ***
*** Bug 55196 has been marked as a duplicate of this bug. ***
*** Bug 99274 has been marked as a duplicate of this bug. ***
*** Bug 61967 has been marked as a duplicate of this bug. ***
Created attachment 130707 [details] Valgrind log of opening the minimal testcase Arch Linux 64-bit, KDE Plasma 5 Version: 5.4.0.0.alpha0+ 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
*** Bug 65881 has been marked as a duplicate of this bug. ***
*** Bug 64997 has been marked as a duplicate of this bug. ***
*** Bug 60501 has been marked as a duplicate of this bug. ***
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?
(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.
By the number of duplicate bugs, I think we should give this a higher priority...
This one should be of highest priority because of duplicates that are questionable.
Created attachment 156731 [details] Flamegraph 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 :-).
@Noel, I thought you might be interested in this issue...
(In reply to Xisco Faulí from comment #26) > @Noel, I thought you might be interested in this issue... Another anchoring issues..
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.
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 ***
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.