Description: I have some documents created with LibreOffice 4. After upgrading to LibreOffice 6, all these files crashe the program (making it not responding). I've tried installing LibreOffice 5 and it's ok, they can be opened. But not starting from the first version of LibreOffice 6.0. I don't know which is the problem, so I'll atatch the file to the bug report in order to let you go take a look into it and reproduce the problem. It's just a school report with tables and some page footers. This problem happens in every computer I've tried under Windows (haven't tried on Linux) with the program just installed. Just with LibreOffice 6, the current version available! Steps to Reproduce: 1. Try to open the file. 2. LibreOffice crashes and starts not responding. 3. Try again with the same result. Actual Results: LibreOffice crashes, Expected Results: Opening the file correctly as LibreOffice 4 and 5 do. Reproducible: Always User Profile Reset: Yes Additional Info:
Created attachment 150209 [details] An example of file which can't be opened with LibreOffice 6 This is one of the files that crushes LibreOffice 6 but works under LibreOffice 4 or 5.
Reproducible with Version: 6.2.2.2 (x64) Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL
Not reproducible with Version: 6.0.0.1 (x64) Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a CPU threads: 12; OS: Windows 10.0; UI render: GL; Locale: ru-RU (ru_RU); Calc: group
I've tried: Reproducible with Version: 6.0.7.3 (x64) Reproducible with Version: 6.1.0.1 (x64)
Regression after https://git.libreoffice.org/core/+/18765b9fa739337d2d891513f6e2fb7c3ce23b50
Similar to bug 116293... it hangs on Linux...
this bug, as reported, is a duplicate of bug 122892 there is another performance problem though, which is *not* an infinite loop but at least in a debug build it's taking a bloody long time scaling a bitmap inside a metafile that must be somewhere in the document to a width of 865 million pixels; this is due to these values read from the metafile: MetaBmpExScaleAction::Read() p maPt $43 = Point = { x = 621353314, y = -1397620223 } p maSz $44 = Size = { width = 1917665794, height = 242 } this happens while creating preview image in SfxPickListImpl::AddDocumentToPickList() during load. after removing this call, there's no perf issue; would be interesting to know if the metafile causes perf problems in release build as well, which would be a *separate* bug from this one of course... *** This bug has been marked as a duplicate of bug 122892 ***
(In reply to Michael Stahl (CIB) from comment #7) > there is another performance problem though, which is *not* an infinite loop filed as bug 125153