Bug 135809 - libreoffice hangs after reading big odt files only vers. 7*
Summary: libreoffice hangs after reading big odt files only vers. 7*
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2020-08-16 15:38 UTC by gerdl
Modified: 2020-11-23 04:59 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
big odt file, rename in lohangup.odt, hangs after reading in (1.82 MB, application/vnd.oasis.opendocument.text)
2020-08-16 15:45 UTC, gerdl 		Details
lo file (1.82 MB, application/vnd.oasis.opendocument.text)
2020-08-16 15:48 UTC, gerdl 		Details
Example file (3.22 KB, text/plain)
2020-08-29 12:48 UTC, Telesto 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description gerdl 2020-08-16 15:38:00 UTC 
Description:
libreoffice hangs after reading big odt-files. the process consumes more and more memory (after waiting about 1 hour). no problems with version 6.4.6

Steps to Reproduce:
1.read in the appended file with version 7.0.1.1, try to work, lo hangs and eats memory
2.
3.

Actual Results:
you have to kill down libre-office

Expected Results:
libre office 7.0.1.1 hangs


Reproducible: Always


User Profile Reset: No



Additional Info:
after reading the file you should be able to work with. no problem with versions until 6.4.6.2
Comment 1 gerdl 2020-08-16 15:45:28 UTC 
Created attachment 164355 [details]
big odt file, rename in lohangup.odt, hangs after reading in
Comment 2 gerdl 2020-08-16 15:48:53 UTC 
Created attachment 164357 [details]
lo file

second transmission mysterious and erraneus comments from bugzilla
Comment 3 Telesto 2020-08-16 22:49:23 UTC 
Repro with
Version: 7.1.0.0.alpha0+ (x64)
Build ID: <buildversion>
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

not with
Version: 6.0.5.0.0+
Build ID: 15ea1cda0b3c37ff944ad9a239b7ed453e8b0591
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 4 gerdl 2020-08-29 09:31:15 UTC 
the bug also appears in lo rc2 7012. I think the bug is very critical because libre offeice is not usable
Comment 5 Telesto 2020-08-29 12:48:28 UTC 
Created attachment 164850 [details]
Example file

Bisected to
author	Justin Luth <justin.luth@collabora.com>	2020-04-22 11:43:22 +0300
committer	Miklos Vajna <vmiklos@collabora.com>	2020-05-07 14:06:16 +0200
commit 99c4fefdbb6129a58421b9c7f4a005f868a0e701 (patch)
tree 0e2df54c625c89a5115a98cb6eeeb027838f2f47
parent ac0112ecefd64094b150390fc36f9f56d19a4d87 (diff)
tdf#98409 doc export: export (non-default) cell margins
Previously, the only cell margins that were being
exported were the row defaults from the last column.

These cell margins are tricky, because multiple
cells and multiple sides can be combined together
into a single definition.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=99c4fefdbb6129a58421b9c7f4a005f868a0e701
A previous commit for tdf#73056 was needed to import
these sequences.
Comment 6 Telesto 2020-08-29 12:50:10 UTC 
@Justin
I bibisected this to a commit of yours, but totally convinced about the result.
Comment 7 Justin L 2020-08-29 13:16:34 UTC 
Yeah, that code is not even touched for ODT. It must be something else.
Comment 8 gerdl 2020-10-05 20:38:35 UTC 
is fixed since 7.0.2
Comment 9 sdc.blanco 2020-10-05 21:53:26 UTC 
Changing to WORKSFORME  ( Unlike FIXED, exact fix commit is not known.)