Description: hi, LO 6.2, i copy image from firefox and paste in LO calc simple and works but works image move (position x,y) but for scaling size (dimensions) process is full and memory is growning up or loading up until full memory, my pc 32gb: starts full memory until 30gb so i need to kill process..so you can see my screen record , has full information for ISSUE.. so i did try update to 6.4 LO calc same issue!! maybe it is high critical bug.. Versione: 6.4.3.2 Steps to Reproduce: 1.open CALC and insert file png 2.try change dimensions (size, drag) 3.start full meomory and total block.. Actual Results: it is loading all memory until full memory (see screen record include) Expected Results: only, i kill process.. Reproducible: Always User Profile Reset: No Additional Info: i did repruce ever ever times.. all times..any times..
Created attachment 160359 [details] this is screen record see all information details.. screen record has all information details..
Created attachment 160459 [details] Image for testing I can not reproduce with a fresh document and your graphic. I tested with gtk3 version. 6.4 and latest master. Arch Linux 64-bit Version: 6.4.3.2 Build ID: 6.4.3-1 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Arch Linux 64-bit Version: 7.0.0.0.alpha0+ Build ID: 8af2c4e3a517e3b75f2ace971... CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 5 May 2020
Created attachment 160647 [details] this file ODS i did open libreoffice Versione: 6.4.2.2 Build ID: 40(Build:2) Thread CPU: 24; SO: Linux 5.3; Resa interfaccia: predefinito; VCL: kf5; Versione locale: it-IT (it_IT.UTF-8); Lingua interfaccia: it-IT Calc: threaded i can reproduce always.. with this file ODS.. i dont know why.. please for Buovjaga,Ilmari,Korrawit can try with this file ok? feedback to report bug thank you manuel
CONFIRMED on my system: Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.10 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group Steps: 1. open attachment 160647 [details] from comment 3 2. try to move the "toast" image What to expect: the image moves freely Actual results: it seemed to be locked into uppermost part of the document 3. try to reduce the image size by clicking on the bottom-right and drag it into the middle of the image (as demonstrated in the video clip attachment 160359 [details] from comment 1) What to expect: the image shrinks Actual results: libreoffice used all of RAM and the whole computer crashed! So, beware, the whole system crashed and I need to hard-reset my computer. Set the status and version accordingly. Thank you Manuel for reporting this bug.
Sorry, I forgot to clean-up some fields: - Edit title - Raise the severity to critical as it causes crash - Reset assignee to default Note: I don't have time to test on a clean profile, so I leave this to others.
Not repro on Windows Version: 7.0.0.0.alpha1 (x64) Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI: en-US Calc: threaded @Buovjaga Is this a specific distro packaging issue? We are talking about OpenSuse/ Ubuntu builds
(In reply to Korrawit Pruegsanusak from comment #4) > CONFIRMED on my system: > Version: 6.0.7.3 > Build ID: 1:6.0.7-0ubuntu0.18.04.10 > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; > Locale: en-US (en_US.UTF-8); Calc: group This is super old, so it would be nice if you tested with a master build. For me, the memory use does increase to over 1GB, but it does not grow forever. Arch Linux 64-bit Version: 7.0.0.0.alpha1+ Build ID: e84d6f512fceb8b354b2d111193a9fd7d834acc5 CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3; Locale: en-US (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 11 May 2020
(In reply to Buovjaga from comment #7) > For me, the memory use does increase to over 1GB, but it does not grow > forever. > > Arch Linux 64-bit > Version: 7.0.0.0.alpha1+ > Build ID: e84d6f512fceb8b354b2d111193a9fd7d834acc5 > CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3; > Locale: en-US (fi_FI.UTF-8); UI: en-US > Calc: threaded > Built on 11 May 2020 And that's even a lot, IMHO. It's 305 MB for me Version: 7.0.0.0.alpha1 (x64) Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI: en-US Calc: threaded Same mem usage on 6.4.3?
(In reply to Telesto from comment #8) > Same mem usage on 6.4.3? Good point: it is catastrophic with 6.4.3 and sadly with 6.4.4 as well. Only way out is Ctrl-Alt-backspace. The good news is that when I tried with bibisect repo 6.5, I can repo the catastrophe in the oldest and then 1000 commits before master, I see a state where there is NO memory hogging. So I should be able to both reverse-bisect the fix to the catastrophy AND bisect the cause of the more minor memory hogging seen in current master. I don't have time to do this immediately, though. Maybe in a couple of hours or more.
The commit that fixes the catastrophic memory leak for 7.0.0 is this: https://git.libreoffice.org/core/+/62ac8333999c661432adb0a18245a399daa89dcb%5E!/ tdf#130655 callback interface for 3D and secure dash I double-checked by flipping between it and the previous commit in Linux 6.5 bibisect repo. Armin: could your commit be backported to 6.4? 6.4.4 is going RC2 this week, but of course it would be great to have the fix in it. Would have to negotiate with release manager. NOTE: testing the bad state on Linux *will cause your graphical session to freeze*!!! I bisected it by always pressing Ctrl-Alt-backspace when the freeze hit. It went to the login screen, I logged in and then I could kill soffice.bin via htop. Regarding the more recent memory hogging I mentioned in comment 9, I bisected and it is the same (general) issue as bug 132536.
Also reproduced in Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.19; Render: default; Locale: en-US (en_US.UTF-8)
I do confirm the issue is fixed in Version: 7.0.0.0.alpha1+ Build ID: 1ffe59ef31186e36ad0aa7bbcdd32e407ee8d26c CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11; Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Closing as VERIFIED FIXED. Regarding the backport topic, LibreOffice 6.4.4 RC2 was tagged a couple of hours ago, meaning 6.4 branch is becoming stable after 6.4.4's release and there are only 2 minor releases left before 6.4 branch reaches the end of life. Considering Armin's commit might introduce regressions and this issue has been around for a while ( 5.2 or even before ) I would prefer not to backport it to 6.4 branch and wait until 7.0 is released. My 2 cents
On top of what I said in my previous comment, the issue is not reproducible in Versão: 6.4.3.2 (x64) ID da versão: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 Processos do CPU: 1; SO: Windows 6.1 Service Pack 1 Build 7601; Gestão da interface: padrão; VCL: win; Configuração regional: es-ES (es_ES); Idioma da interface: pt-PT Calc: threaded so another reason not to backport it
Meanwhile, I've reported bug 133003 regarding the image position on Linux after moving it
ok, thank you for fixed it the bug (i start bug :-P) but is there appimage for libreoffice 7.0 7.0.0.0.alpha1 (x64)..? thank you
hi i did installed 7.0 alpha1 rpm on my opensuse 15.2 open with file attach but there is strange number of size:height = -1.604,00 cm i try resize but not work.. instead width i can resize... @ Xisco Faulí did you check it? i did screen record i will put here.. but GOOD POSITIVE IS: NOT CRASH or NOT MEMORY FULL.. but strange bug for size..this will be fix..? thank you note: SUPER COOL for GRAPHIC INTRO (starting) COMPLIMENT!!!
Created attachment 160774 [details] SCREEN RECORD WITH LO 7.0-ALPHA1 SCREEN RECORD WITH LO 7.0-ALPHA1
Comment on attachment 160774 [details] SCREEN RECORD WITH LO 7.0-ALPHA1 (In reply to manuel from comment #16) > hi > i did installed 7.0 alpha1 rpm on my opensuse 15.2 > open with file attach but there is strange number of size:height = -1.604,00 > cm i try resize but not work.. instead width i can resize... > > @ Xisco Faulí did you check it? > > i did screen record i will put here.. Hi Manuel, I saw that you already mentioned and uploaded the clip at bug 133003. Please follow the problem there. We try to separate each bug into only one problem, not combining it. So, I mark the latest screen record as obsolete. Thank you :) And thank you for verifying the fix of this bug!