Download it now!
Bug 136265 - FILEOPEN DOCX: Memory usage exploding (images in table)
Summary: FILEOPEN DOCX: Memory usage exploding (images in table)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Regressions-cairo-speedup
  Show dependency treegraph
 
Reported: 2020-08-29 13:12 UTC by Telesto
Modified: 2020-08-29 21:16 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (1.65 MB, application/vnd.oasis.opendocument.text)
2020-08-29 18:37 UTC, Telesto
Details
Reduced Example file (1.65 MB, application/vnd.oasis.opendocument.text)
2020-08-29 18:53 UTC, Telesto
Details
Reduced Example file (1.65 MB, application/vnd.oasis.opendocument.text)
2020-08-29 19:02 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-08-29 13:12:08 UTC
Description:
FILEOPEN DOCX: Memory usage exploding (images in table)

Steps to Reproduce:
1. Open the attached file
2. Save as DOCX
3. File reload

Actual Results:
Loading slow; surely needed 3 GB

Expected Results:
Not so


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 6640d7f405d2970ba2825a9455926cc803284d01
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

and in
6.4 (after scrolling the second which actually contain the images)

opening pretty fast (except most of the images show up as empty frames)
Version: 6.3.0.0.beta1+ (x86)
Build ID: 5cfac16dbd4af456a7fb6d52c8953c69a72ba2ba
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL

and in
Version: 6.2.0.0.alpha0+
Build ID: 2bc84658cce1df5050fe788dd0c8a0906a1ca2c3
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL

Not in (file opening is however boringly slow)
6.0.5
Comment 1 Telesto 2020-08-29 13:31:49 UTC
Older versions tend to behave similar..

Also seen in
3.5.0.3
Comment 2 Telesto 2020-08-29 13:35:03 UTC
@Justin
Any clue whats going wrong here; or a person who might now.. Can't decide between Miklos, Tomaz, or even Armin. As it's about images loading at docx import.
Comment 3 Justin L 2020-08-29 18:19:21 UTC
Armin never responds to anything. I've Tomaz speaking intelligently about image stuff.

There is no attached or mentioned file here. You should also bibisect when it switches from fast/missing images to slow/displayed images.
Comment 4 Telesto 2020-08-29 18:37:07 UTC
Created attachment 164855 [details]
Example file
Comment 5 Telesto 2020-08-29 18:53:28 UTC
Created attachment 164856 [details]
Reduced Example file
Comment 6 Telesto 2020-08-29 19:02:40 UTC
Created attachment 164857 [details]
Reduced Example file
Comment 7 Telesto 2020-08-29 19:07:46 UTC
@Buovjaga
You're system slightly better equipped (powerful/more ram). I'm going OOM with DOCX export of the Reduced example (I need to kill the process before my system freezes) with 7.1. Older versions are working' of empty image frames & slow loading.
Comment 8 Telesto 2020-08-29 19:09:28 UTC
(In reply to Telesto from comment #7)
> @Buovjaga
> You're system slightly better equipped (powerful/more ram). I'm going OOM
> with DOCX export of the Reduced example (I need to kill the process before
> my system freezes) with 7.1. Older versions are working' of empty image
> frames & slow loading.
Comment 9 Buovjaga 2020-08-29 20:00:30 UTC
(In reply to Telesto from comment #7)
> @Buovjaga
> You're system slightly better equipped (powerful/more ram). I'm going OOM
> with DOCX export of the Reduced example (I need to kill the process before
> my system freezes) with 7.1. Older versions are working' of empty image
> frames & slow loading.

The export itself is fine, but after reloading mem use peaks at 13,8GB. The good peaking is only 3,7GB.

Bibisected with linux-64-7.0 repo. In the bibisect, I considered as bad also the increase to 6,8GB. I only kept opening the same DOCX, I did not re-export it during the bibisect.

https://git.libreoffice.org/core/commit/828504974d70111e4a35b31d579cf42fe660a660
tdf#130768 speedup huge pixel graphics Cairo

Adding Cc: to Armin Le Grand
Comment 10 Telesto 2020-08-29 20:09:42 UTC
(In reply to Buovjaga from comment #9)
Thanks for the bibisect. They 3,7 GB will still freeze my system, I guess. 

Few questions
1) Only for my impression: which file did you use? 12 GB with the reduced file or the original? 
2) Which backend did you use. X11, GTK3 & does the opening go smooth? It's pretty bad on Windows back to 3.5.0. Read-errors for images etc. Constant CPU hammering (after file open)
Comment 11 Buovjaga 2020-08-29 21:16:52 UTC
(In reply to Telesto from comment #10)
> (In reply to Buovjaga from comment #9)
> Thanks for the bibisect. They 3,7 GB will still freeze my system, I guess. 
> 
> Few questions
> 1) Only for my impression: which file did you use? 12 GB with the reduced
> file or the original?

Reduced.

> 2) Which backend did you use. X11, GTK3 & does the opening go smooth? It's
> pretty bad on Windows back to 3.5.0. Read-errors for images etc. Constant
> CPU hammering (after file open)

Now I tried with gen backend and surprisingly the explosion to 13,8GB was not visible. So only with gtk3 and kf5.

By opening I assume you mean opening the .odt file. It certainly is a lot smoother than the .docx. Mem use never rises above 800MB with non-gen. With gen, the opening is actually instant!