Bug 133440 - Closing LibreOffice with some images on the clipboard takes a while and needs up to 2 GB ram
Summary: Closing LibreOffice with some images on the clipboard takes a while and needs...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, perf
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2020-05-27 13:01 UTC by Telesto
Modified: 2024-03-07 21:01 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (4.09 MB, application/vnd.oasis.opendocument.text)
2020-05-27 13:01 UTC, Telesto
Details
Bibisect log (2.90 KB, text/plain)
2020-05-27 20:20 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-05-27 13:01:32 UTC
Description:
Closing LibreOffice with some images on the clipboard takes a while and needs up to 2 GB ram

Steps to Reproduce:
1. Open the attached file (and use a process monitoring tool)
2. CTRL+A
3. CTRL+C
4. CTRL+Q

Actual Results:
Notice the memory usage increasing up to 2 GB peak

Expected Results:
I haven't see this in the x32 builds
Did only test x64 builds until 6.3


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.alpha1+ (x64)
Build ID: 21875558f6c478f07d68ff39e025d7ffd451674f
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
Comment 1 Telesto 2020-05-27 13:01:56 UTC
Created attachment 161332 [details]
Example file
Comment 2 Telesto 2020-05-27 13:15:47 UTC
Also in 5.0.0.5 x64

The memory usage less extreme with x32 builds, and clipboard content appears to be broken too.

Repro with
4.3

not repro with
4.2
Comment 3 Telesto 2020-05-27 20:20:25 UTC
Created attachment 161356 [details]
Bibisect log

Bisected to
author	Caolán McNamara <caolanm@redhat.com>	2014-07-14 11:36:32 +0100
committer	Michael Stahl <mstahl@redhat.com>	2014-07-22 17:07:26 +0000
commit 41fde63b3ec4da0a4a6636105dd7b65fdfc7ad44 (patch)
tree ccc305921f8b9fc991e36546a826f47b73b38438
parent 40eddf707f8f56fa63ddba9f4713a32dba43bd62 (diff)
Resolves: fdo#52226 swap in graphics on .docx and .rtf export

https://cgit.freedesktop.org/libreoffice/core/commit/?id=41fde63b3ec4da0a4a6636105dd7b65fdfc7ad44
Comment 4 Telesto 2020-05-27 20:21:50 UTC
@b
A conformation would be nice, even if not Calc ;-). Windows only I assume
Comment 5 b. 2020-05-28 19:43:23 UTC
yes, there is high memory usage, and quite some time solid cpu usage as well, and some mem still blocked after close of writer ... 

i'd read sometimes somwhere that LO made efforts to be able to do a paste still after the original document vanished ... may be it's neccessary for comfort like that ... ???

this function is working as long as one instance of the same version is still open, but the mem/cpu usage happens on closing of the last instanc? after that in a new instance copy is tried, but brings only text-placeholders, check it out ... 

can't judge if there is intended use or just waste of ressources ... hope some of the pros can ... 

had no time to check against old ver., 6.5.0.0 and 7.0.0.0.a1+ are slow, thus can't tell if regression ...
Comment 6 Telesto 2020-05-28 19:49:12 UTC
Adding CC to Caolán McNamara

Note: it's probably Windows only
Comment 7 Caolán McNamara 2020-05-28 20:06:38 UTC
I see that the images are 4000x2664 pixels in size. On the face of things I wouldn't see it as a regression as such, seeing as saving the document without its images isn't a state we want to revert to, nor is losing the clipboard contents on exit. Though clearly it would be better to produce more optimized output if that's possible.
Comment 8 Telesto 2020-05-28 20:15:39 UTC
The memory usage is less problematic with smaller images (didn't check that). But the behavior is still noticeable with smaller ones.. 

And the copy to the clipboard is somehow broken to. Relaunching LibreOffice & paste produces not the right results.. And that part did work quite well before

Anyway, thanks for responding so fast :-)
Comment 9 QA Administrators 2022-05-29 03:41:13 UTC Comment hidden (obsolete)
Comment 10 wjsim 2024-03-07 21:01:21 UTC
This bug is still present in:

Version: 24.2.1.2 (X86_64) / LibreOffice Community
Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac
CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

As well as:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6a064b1967e06e40be40817deff99d00c1a8554f
CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded


While it's worth noting that it is no longer a 2gb of ram usage, however CPU and ram usage does spike up for a split second. I've tried it with text in my clipboard instead, and have not been able to reproduce the same spike in CPU and ram usage.