Steps to reproduce: 1. Open attachment 58704 [details] from bug 47461 -> LibreOffice hangs Reproduced in Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: 68b6004fe9df184bcbaf46dd53abfec228219df6 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded [Bug found by office-interoperability-tools]
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=798b69087119c01a3b51e0bb3240ef35cfededeb 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) tree a498de98b34bacf760b208d3cc650c2a2f68ae58 parent fb5247bf587518eaa01cf5d54dceddf73827d740 (diff) tdf#104254 sw DOCX import: fix text wrapping in headers Bisected with: bibisect-linux64-7.2 Adding Cc: to Daniel Arato
DOC is 66 pages in MSO and LO opens 300 with very high CPU. MSO created DOCX opens OK.
*** Bug 142760 has been marked as a duplicate of this bug. ***
attachment 124404 [details] from bug 99349 is also affected by this issue It has 88 pages in MSO and 110 in LibreOffice
Created attachment 172763 [details] Docx version of the example file Interestingly the docx version converted with Word 2019 does not hang.
(In reply to NISZ LibreOffice Team from comment #6) > Created attachment 172763 [details] > Docx version of the example file > > Interestingly the docx version converted with Word 2019 does not hang. I believe the root problem here is what is described in bug 142760
The offending commit was reverted with: https://bugs.documentfoundation.org/show_bug.cgi?id=104254#c14 Will be more careful next round.
(In reply to Xisco Faulí from comment #1) > Regression introduced by: > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=798b69087119c01a3b51e0bb3240ef35cfededeb > tdf#104254 sw DOCX import: fix text wrapping in headers This commit has been reverted, so for the moment, this is resolved. However, that commit just triggered an existing layout condition that we can't handle. So the revert just masks this again. Oh well, there are so many crash/freeze bug reports that there isn't much point in leaving this one open. And no point for adding a unit test because there has not been a true fix.
(In reply to Justin L from comment #9) > However, that commit just triggered an existing layout condition that we > can't handle. So the revert just masks this again. Oh well, there are so > many crash/freeze bug reports that there isn't much point in leaving this > one open. And no point for adding a unit test because there has not been a > true fix. Should we set this bug to WONTFIX perhaps?
(In reply to Dániel Arató (NISZ) from comment #10) > (In reply to Justin L from comment #9) > > However, that commit just triggered an existing layout condition that we > > can't handle. So the revert just masks this again. Oh well, there are so > > many crash/freeze bug reports that there isn't much point in leaving this > > one open. And no point for adding a unit test because there has not been a > > true fix. > > Should we set this bug to WONTFIX perhaps? Actually there are two problem here, the hang and the increase in the number of pages. The hang might be a consequence of the second problem, so let's close this as a duplicate of bug 142760, where the problem of the number of pages was first reported *** This bug has been marked as a duplicate of bug 142760 ***