Description: Memory usage for 4 documents containing a table of 10 columns 1500 cells doubled Steps to Reproduce: 1. Open Writer 2. CTRL+F12 3. Column 10: cells 1500 4. CTRL+N + step 2/3 (until 4 documents open) Actual Results: LibO6.3 295 MB on 32x with automatic spell checker enabled; without 255 Libo4.4.7.2: +/-150 mb Expected Results: Something like 4.4.7.2 Reproducible: Always User Profile Reset: No Additional Info: Version: 6.3.0.0.alpha0+ Build ID: 20ea90a557b5bc744fd234e3a20ab1db484cf88b CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-03-22_03:21:58 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: threaded
Thank you for reporting the bug. I have observed following memory usage with automatic spell checker enabled Version: 6.3.0.0.alpha0+: 120.2MB Version: 6.2.1.2: I can not reproduce the bug in Version: 6.2.1.2 (x64) Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL Version: 6.3.0.0.alpha0+ (x64) Build ID: 91cdf22b88a4f7bec243c8fb187627e766d3294c CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-08_00:38:10 Locale: en-US (en_US); UI-Language: en-US Calc: CL
In Version 6.2.1.2: 134.7MB
I repro - in 6.3 I see over 200 MB while in 5.0 it is 80 MB. There is a bump from 120 MB to 190 MB in the last commit of win32-bibisect-6.0 and the first commit of win32-bibisect-6.1, so I am unable to bibisect. Telesto: can you try the bibisect repos? Also seen on Linux. Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: b8f33d053c2cbf05872cf9ddfeff4cc302ee281f CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 20 April 2019
Created attachment 150975 [details] Bibisect Bisected to author Michael Meeks <michael.meeks@collabora.com> 2016-07-11 15:12:38 +0100 committer Michael Meeks <michael.meeks@collabora.com> 2016-07-12 08:39:01 +0000 commit c44726c48228d9c6a5960e302b1c0bd16b0099c4 (patch) tree 26c3fbd11a29af5de6d555dcec3076dde9701378 parent 9c711f05fa10dc70e4257a1f48d43f539353541a (diff) desktop: validate OpenCL drivers before use. OpenCL validation needs to happen before drivers are used in anger. This should isolate any crashes, and/or mis-behavior to We use app version, CL driver version and file time-stamp to trigger re-testing the device. If anything fails: hard disable OpenCL. We use an opencl validation sheet (cl-test.ods) and install it. It is a minimal CL set - it requires a very short formula group length, and combines several CL functions into few formulae to test more. The sheet structure, in particular the manual squaring / SQRT is necessary to stick within the default CL subset, and ensure that formulae are CL enabled from the root of the dependency tree up. https://cgit.freedesktop.org/libreoffice/core/commit/?id=c44726c48228d9c6a5960e302b1c0bd16b0099c4 Memory usage is in normal range in newer version when disabling OpenCL (or using with OpenCL prior to the given commit )
Note: comment 0 is bit of distracting.. table stuff doesn't really matter.. can be seen without too (however the need to be some user interaction to fully load everything . Clicking Tools menu or typing something).. At least for 5.3 branch (see bug 104332)
(In reply to Telesto from comment #4) > Memory usage is in normal range in newer version when disabling OpenCL (or > using with OpenCL prior to the given commit ) Then how come I could repro even though I did not have OpenCL enabled? It sounds weird that a Calc thing would affect Writer.
(In reply to Buovjaga from comment #6) > (In reply to Telesto from comment #4) > > Memory usage is in normal range in newer version when disabling OpenCL (or > > using with OpenCL prior to the given commit ) > > Then how come I could repro even though I did not have OpenCL enabled? Valid point > It sounds weird that a Calc thing would affect Writer. Maybe, maybe not.. the OpenCL check happens on initialization of LibO.. so maybe not properly disposed or something like that .. Bibisected this type of issue is like hell IMHO. Never certain what you are comparing between versions. Compiler stuff. Memory bug A got fixed in exchange for bug B :-). Dictionary's.. So hard to tell what to expect Bug 104332 increased mem usage when launching.. IMHO Layout caching did increase mem usage also Anyway probably stacking multiple issue around here, lovely (or my drivers are broken somehow) Results with Version: 6.1.0.0.beta2+ Build ID: 033400a7524813b4eccf8f90a7647bc0121e75dd 169 MB without OpenCL & OpenGL 219 MB with OpenCL enabled & without OpenGL 370 MB with OpenGL without OpenCL Results with Version: 6.3.0.0.alpha0+ Build ID: 3083fe569f96bf0289da1e9d0ef7da15ab22e2f6 230 without OpenCL & OpenGL 294 with OpenCL & without OpenGL enabled 404 with OpenGL without OpenCL
Main root issue probably older.. 190 MB without OpenCL and OpenGL with LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
(In reply to Telesto from comment #8) > Main root issue probably older.. 190 MB without OpenCL and OpenGL with > LibreOffice 3.5.7.2 > Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b But this sounds like the usage has changed like a rollercoaster since 3.5, high, low and now again high.
(In reply to Buovjaga from comment #9) > (In reply to Telesto from comment #8) > > Main root issue probably older.. 190 MB without OpenCL and OpenGL with > > LibreOffice 3.5.7.2 > > Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b > > But this sounds like the usage has changed like a rollercoaster since 3.5, > high, low and now again high. I would say so.. but there are so many variables.. obvious ones OpenCL, OpenGL, Spell Checker and the glitch observed in comment 3 (which i have seen a few times; and doesn't make much sense either) Still think that there is something off somewhere..but I give up for now
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://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
Result is 326 MB with automatic spell checking at the moment. Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 680(Build:0) CPU threads: 2; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded