Bug 119023 - Fileopen DOC: OOM/ missing or black images when opening a file contains multiple images
Summary: Fileopen DOC: OOM/ missing or black images when opening a file contains multi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4 all versions
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: DOC-Images DOC-Anchor-and-Text-Wrap
  Show dependency treegraph
 
Reported: 2018-07-31 17:42 UTC by Telesto
Modified: 2023-05-31 20:45 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Example file (4.10 MB, application/vnd.oasis.opendocument.text)
2018-07-31 17:42 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-07-31 17:42:06 UTC
Description:
Fileopen DOC: OOM/ missing or black images when opening a file contains multiple images

Steps to Reproduce:
1. Open the attached ODT
2. Save a copy as DOC
3. Close the ODT
4. Open the DOC (monitor memory usage)

Actual Results:
Crash with x32 builds & High memory usage with X64

Expected Results:
More efficient memory usage


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 6.2.0.0.alpha0+
Build ID: 1b21ff86effe58ae368457de8fec654ba4c8edd9
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-07-30_03:13:35
Locale: nl-NL (nl_NL); Calc: CL

but not in
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL
Comment 1 Telesto 2018-07-31 17:42:30 UTC
Created attachment 143858 [details]
Example file
Comment 2 Roman Kuznetsov 2018-07-31 18:07:37 UTC
confirmed in

Version: 6.1.0.2 (x64)
Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
Locale: ru-RU (ru_RU); Calc: CL

very long process of importing of .doc file and LO had over 3.5Gb of memory in this time. But after ending of importing LO freed memory.

And if this case gives crash for 32 bit build of LO, may be need to up Importance?
Comment 3 Xisco Faulí 2018-08-01 08:30:25 UTC
I can't reproduce it in

Version: 6.2.0.0.alpha0+
Build ID: 72b099d279e7096d41a04fe8c0dd493a5fc18a33
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
Comment 4 Xisco Faulí 2018-08-01 08:33:19 UTC Comment hidden (obsolete)
Comment 5 Xisco Faulí 2018-08-01 08:35:38 UTC
(In reply to kompilainenn from comment #2)
> confirmed in
> 
> Version: 6.1.0.2 (x64)
> Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106
> CPU threads: 4; OS: Windows 10.0; UI render: GL; 
> Locale: ru-RU (ru_RU); Calc: CL
> 
> very long process of importing of .doc file and LO had over 3.5Gb of memory
> in this time. But after ending of importing LO freed memory.
> 
> And if this case gives crash for 32 bit build of LO, may be need to up
> Importance?

Hi Kompi,
What happens if you disable OpenGL?
In my case, I'm using 32 bits and everything seems to work correctly...
Comment 6 Telesto 2018-08-01 09:39:33 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2018-08-02 10:23:45 UTC
Forgot what I said, I can reproduce it in

Versión: 6.1.0.2
Id. de compilación: b3972dcf1284967612d5ee04fea9d15bcf0cc106
Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; 
Configuración regional: es-ES (es_ES); Calc: group threaded
Comment 8 Xisco Faulí 2018-08-02 10:53:52 UTC
So I don't reproduce the crash, but it hangs here ( I killed it after 10 minutes ).
Same behaviour in

Versión: 4.4.0.3
Id. de compilación: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Configuración regional: es_ES
Comment 9 QA Administrators 2019-08-03 03:05:54 UTC Comment hidden (obsolete, spam)
Comment 10 QA Administrators 2022-08-18 03:39:41 UTC Comment hidden (obsolete, spam)
Comment 11 Justin L 2023-05-31 20:12:14 UTC
I can't reproduce in 7.6 or 7.0. No missing images and no hung cpu.
Comment 12 Telesto 2023-05-31 20:45:56 UTC
(In reply to Justin L from comment #11)
> I can't reproduce in 7.6 or 7.0. No missing images and no hung cpu.

True, no missing images..

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 22950a9b008e1bb22fa9e54b5d45715e25fee764
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 threaded

However the initial bug was reported by an x32 build. 2GB limited, made it crash


Anyhow the funny part
1. Opening and the ODT and scrolling =  226 MB ram usage (with Skia Raster)
2. Open the DOC and scrolling and scrolling = 2,5 GB ram usage (with Skia Raster) with x64 build

I'm really unfamiliar with the binary doc format. 

1. I assume the same image being loaded by reference (stored a single time in ODT) and doc export making all those images unique.

There are all sorts of optimizations: like (https://tomazvajngerl.blogspot.com/2018/01/improving-image-handling-in-libreoffice.html) 

And Skia has optimizations too to reduce RAM usage. 

However the optimizations apparently fail with DOC, because the how images are stored and handled.. But that's only a guess, unfamiliar with the DOC format

---
Something different I observed (but off-topic  here)
1. Open the ODT
2. Export it to DOCX 
3. File -> Reload -> most images are invisible