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
Created attachment 143858 [details] Example file
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?
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
I can't 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 either...
(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...
(In reply to Xisco Faulí from comment #5) 1. To be sure: you did open the exported Word 97-2003 DOC? 2. It doesn't crash persistently on x32, but lots of images are missing (white squares without OpenGL; black squares with OpenGL) 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
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
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
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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
I can't reproduce in 7.6 or 7.0. No missing images and no hung cpu.
(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