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.
Dear Mike Kaganski, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #31) > Dear Mike Kaganski, > > To make sure we're focusing on the bugs that affect our users today, > LibreOffice QA is asking bug reporters and confirmers to retest open, > confirmed bugs which have not been touched for over a year. > > There have been thousands of bug fixes and commits since anyone checked on > this bug report. During that time, it's possible that the bug has been > fixed, or the details of the problem have changed. We'd really appreciate > your help in getting confirmation that the bug is still present. > > If you have time, please do the following: > > Test to see if the bug is still present with the latest version of > LibreOffice from https://www.libreoffice.org/download/ > > If the bug is present, please leave a comment that includes the information > from Help - About LibreOffice. > > If the bug is NOT present, please set the bug's Status field to > RESOLVED-WORKSFORME and leave a comment that includes the information from > Help - About LibreOffice. > > Please DO NOT > > Update the version field > Reply via email (please reply directly on the bug tracker) > Set the bug's Status field to RESOLVED - FIXED (this status has a particular > meaning that is not > appropriate in this case) > > > If you want to do more to help you can test to see if your issue is a > REGRESSION. To do so: > 1. Download and install oldest version of LibreOffice (usually 3.3 unless > your bug pertains to a feature added after 3.3) from > https://downloadarchive.documentfoundation.org/libreoffice/old/ > > 2. Test your bug > 3. Leave a comment with your results. > 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; > 4b. If the bug was not present in 3.3 - add 'regression' to keyword > > > Feel free to come ask questions or to say hello in our QA chat: > https://web.libera.chat/?settings=#libreoffice-qa > > Thank you for helping us make LibreOffice even better for everyone! > > Warm Regards, > QA Team > > MassPing-UntouchedBug As my original bug report, Bug 60501, was marked as a duplicate of this bug (although this was created later) I did some testing in regards of this bug with the file attached to Bug 60501. OS: Debian Bookworm OS default: LibreOffice 7.4.7 -> Still triggers this Bug, LibreOffice hangs completely Bookworm Backports: LibreOffice 7.5.8 -> Still triggers this Bug, LibreOffice hangs completely Manually Installed: LibreOffice 7.6.2.1 -> Opens file successfully
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.
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