Created attachment 181927 [details] Sample file The attached file is produced (only) with LibreOffice but it can not open it again. I do not know the reason, but there are some rare settings - The document size is custom: 148×42 cm (A5×2). - It has a frame with two columns (= 2. page on the bottom). I tried to open with LO 6, LO 7.1, LO 7.2, LO 7.3 but all versions are hanging during file open.
The document is NOT conformant ODF1.3! Generator: LibreOffice/7.3.5.2$Linux_X86_64 LibreOffice_project/30$Build-2 https://odfvalidator.org/ Do you have a version previous to the issue?
Created attachment 181928 [details] Previous state of the document This is the previous state of the document. This opens normally with LO any version.
Opens fine using Version: 5.0.0.5 (x64) Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b Locale: ru-RU (ru_RU)
Did I miss something? Currently I see: LibO hangs when opening damaged document from unknown source. Reproducible with Installation of Version: 7.3.3.2 (x64) Build ID: d1d0ea68f081ee2800a922cac8f79445e4603348 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE | Calc: threaded | ElementaryTheme | My normal User Profile. But a document saved from Sample " Previous state of the document" with this versions opens without any problems. So the question is: how has Névtelen 1.odt been created? With which version? Do we have a Filesave problem?
Created attachment 181935 [details] Workaround Rainer, the answers on your questions: 1) "Névtelen 1.odt" is produces with: Version: 7.3.5.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: hu-HU Ubuntu package version: 1:7.3.5-0ubuntu0.22.04.1 Calc: threaded 2) This document never seen document processor other the LibreOffice. 3) There is a "Previous state of the document". Steps to reproduce the error manually: - Open the "Previous state of the document" - Set page size to 14,8×42 cm. - Insert a new frame the the first page: 1. width: 14,8 cm, anchor to page, top: 21 cm from entire page 2. borders none + 0,7 cm, columns: 2 with 0,78 cm gap. - Cat the content form 2. page and insert to newly created frame. - Save the document. - Open it. It hangs. 4) And a new information. I experimented and found a workaround: Instead of setting border to 0,7 cm I set Wrap left, right, top, bottom to 0,7 cm and the hanging is gone. Maybe the error will be around the border settings. See the attached "Workaround" file.
(In reply to Rainer Bielefeld Retired from comment #4) > Currently I see: LibO hangs when opening damaged document from unknown > source. (In reply to Gellért Gyuris from comment #0) > The attached file is produced (only) with LibreOffice but it can not open it > again. The problem is a usual layout loop problem, with regression point in the 5.3 release cycle.
Regression after commit 5d9d0f3c979732ade57b9c4c4960dd030ffdc9f9 Author Justin Luth <justin_luth@sil.org> Date Wed Nov 02 15:15:55 2016 +0300 there is a function for that: CalcLineSpace(xx, bEvenIfNoLine)
Created attachment 181950 [details] Nevtelen 1Borders.odt: border line enabled to avoid comment 7 changes. (In reply to Mike Kaganski from comment #6) > The problem is a usual layout loop problem That would be my assessment too. The commit reference is for bug 41542. Previously LO was ignoring border empty spacing when there was no border line, but now that border spacing will be added, affecting the layout slightly. I'm sure it is irrelevant. If you enable the border-line, then it will also hang prior to LO 5.3. Removing regression and bisect flags since these aren't layout commits, and weren't the cause of a can-load-and-modify-in-master but can't-round-trip-the-modification.
Using attachment 181950 [details] from comment 8, it hangs already in LO 3.5. Assuming the layout issue is inherited from OOo.
(In reply to Justin L from comment #9) > Assuming the layout issue is inherited from OOo. Confirmed that it also hangs in OOo 3.2.0.
repro 7.6+ using comment 8's example. The memory usage is not climbing, just one thread that runs at 100% forever.