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: 2025-05-31 03:11 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
Comment 13 QA Administrators 2025-05-31 03:11:20 UTC
Dear Telesto,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug