Bug Hunting Session
Bug 124281 - Files created in LibreOffice 4 which hangs on LibreOffice 6 in every computer
Summary: Files created in LibreOffice 4 which hangs on LibreOffice 6 in every computer
Status: RESOLVED DUPLICATE of bug 122892
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha0+
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: File-Opening tdf#114306-regressions
  Show dependency treegraph
 
Reported: 2019-03-22 21:53 UTC by Jaime
Modified: 2019-05-07 10:06 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
An example of file which can't be opened with LibreOffice 6 (73.35 KB, application/vnd.oasis.opendocument.text)
2019-03-22 21:55 UTC, Jaime
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaime 2019-03-22 21:53:56 UTC
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:
Comment 1 Jaime 2019-03-22 21:55:25 UTC
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.
Comment 2 Mike Kaganski 2019-03-22 21:57:06 UTC
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
Comment 3 Mike Kaganski 2019-03-22 22:00:28 UTC
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
Comment 4 Jaime 2019-03-22 22:42:12 UTC
I've tried:

Reproducible with Version: 6.0.7.3 (x64)
Reproducible with Version: 6.1.0.1 (x64)
Comment 5 Mike Kaganski 2019-03-23 07:57:45 UTC
Regression after https://git.libreoffice.org/core/+/18765b9fa739337d2d891513f6e2fb7c3ce23b50
Comment 6 Xisco Faulí 2019-03-25 13:04:10 UTC
Similar to bug 116293... it hangs on Linux...
Comment 7 Michael Stahl (CIB) 2019-05-06 17:02:30 UTC
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 ***
Comment 8 Michael Stahl (CIB) 2019-05-07 10:06:10 UTC
(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