Description: Clicking on the shape in attachment 173084 [details] ("circular-arrow" saved to .doc) increases the RAM use of LibreOffice up to 1.3 GB, eventually makes the shape disappear, and creates visual artifacts all over LibreOffice. Is this a "memory leak"? This is possibly only a Linux thing. It was originally reported in Bug 142983 but is probably better reported as a separate issue to the malformed shape in DOC. Steps to Reproduce: Use all steps here, or use the attached document and start at step 4: 1. Open attachment 173084 [details] 2. Click on the shape Actual Results: Clicking the shape brings up memory use of LibreOffice between 900 mb and 1.3 GB of memory (depending on version), and hangs the system for a few seconds. Memory use goes back down after a while. In some more recent versions, the shape then disappears. Clicking the area where the shape was will select the invisible object once more, and will bring the memory use up once more. Some visual artifacts might appear in the viewport, in menus, the sidebar, dialogues... See an example video in attachment 173085 [details]. Expected Results: Memory use does not increase dramatically, shape does not disappear, UI does not look broken. Reproducible: Always User Profile Reset: No Additional Info: I am wondering if this has to do with the fact that the malformed shape overflows possibly infinitely to the left side of the document? Shape only disappears in 7.2 beta1 and 7.3 alpha0. Tested in: Version: 6.2.5.2 Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded Version: 7.0.6.2 Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.2.0.0.beta1 / LibreOffice Community Build ID: c6974f7afec4cd5195617ae48c6ef9aacfe85ddd CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 822f128e734f37ee4de9bf5b62640cbec140701e CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded (built today)
Created attachment 173446 [details] visual artifacts in UI A screenshot of visual artifacts seen when continuing using Writer after the memory issue.
Created attachment 173450 [details] i confirm the bug. if computer has less then 4g free libreoffice shuts down. if not it waits and work. i see it consuming memory of the pc.
Created attachment 173453 [details] is going to consume memory...
Created attachment 173454 [details] start memory
Created attachment 173455 [details] end memory 6,6 gb
Comment on attachment 173455 [details] end memory 6,6 gb 6,6 - 3,8 = 2,8 it consumes 2,8gb gb memory...
Created attachment 173457 [details] memory going up Confirm also with Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded
Also in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: eac5977bfc11797eda356560a5e45c51108ef5a1 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Thanks Paulo and Bogdan! Seems to be GTK-specific. I tried without GTK: /opt/libreofficedev7.2/program/soffice -env:SAL_USE_VCLPLUGIN=gen --writer ...and didn't get the same drastic increase in memory use (it only went from 100 to 150 mb, I could move the shape around, it didn't disappear... I could see in the terminal the following warning pop up every time I move the shape around, in case it helps understanding the issue: warn:legacy.osl:20977:20977:svx/source/svdraw/svdmrkv1.cxx:311: SdrMarkView::UndirtyMrkPnt(): Selected points on an object that is not a PolyObj!
I don't think isn't a gtk think but is a generic unix/X thing in that selecting the shape makes it a candidate for the "primary selection" and for some (rather odd look reason) we're generating a huge bitmap from it in case we want to paste it into some other application while the usual pattern is just to state that its possible to paste as that format and not generate it until its explicitly requested.
I think we can defer creating this large transfer bitmap until the moment something actually wants it during a drop, which is the usual pattern for this sort of thing and what I see we're doing with the standard writer images (as opposed to these drawings)
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2012d5b90b64cb3a28862267dafb162c2f85d832 tdf#143257 like graphics defer creating transfer data for drawings until needed It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed in devel, backports in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/bcccbf1a8d8891b7dc60122a380cf648d2998995 tdf#143257 like graphics defer creating transfer data for drawings until needed It will be available in 7.2.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
No problem now. Thanks for this fix. Very important! Verified with Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: c6695a4aabeaae99174b7658f2b813788ecff7f0 CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Thank you, Caolán! No memory increase when selecting the shape in a recent build of master. Now, if the shape is copied, we still get the memory increase, and I can see the UI issues in Writer. Should a different bug report be opened about this, that would probably apply to any operating system? What do you think is the reason for that particular shape to hog memory like that when copied? Is it just that it is huge in size, and therefore we only need Bug 142983? FYI, when pasted into Inkscape, the size of the object is about 587 × 182 cm.
(In reply to stragu from comment #16) > Should a different bug report be opened about this, that would probably apply to any operating system? It would presumably affect all platforms by the time of paste > What do you think is the reason for that particular shape to hog memory like > that when copied? I don't really know, but problems like this have shown up in the past with things like very long dashed/dotted lines which, while they might get cropped in the end, generate large amount of line segments.