Description: I installed LibreOffice 7.5.5.2. I was using LibreOffice Writer and had it open for the course of 2 days. Over those 2 days Writer slowly was consuming more and more RAM and eventually Writer was consuming nearly 5 GB of RAM just to render a 2 page document. Eventually my computer froze and Writer crashed and I'm disappointed because my 2 days of work is gone (I never saved; Google Docs habits). I then uninstalled version 7.5.5.2 and am going to try using v7.4.7 instead and hopefully it is more stable. If not I'll have to find a different document editor or create my own, but I'm already busy writing my own code editor from scratch in Rust (a language that prevents memory leaks) because Vim doesn't suit my wants. Steps to Reproduce: 1.Install LibreOffice 7.5.5.2 on x86-64 Windows 11 2.Use LibreOffice writer for 2 days 3.LibreOffice writer should start using a ton of RAM and eventually crash. Actual Results: I was writing my page in proper MLA format just in case it was formatting on the page causing it to use a ton of RAM. Expected Results: The writer was using nearly 3 GB of RAM and nearly 2 GB of GPU RAM. 5 KB worth of text shouldn't need 3 GB of RAM. Reproducible: Didn't try User Profile Reset: Yes Additional Info: The software should use a small amount of RAM and not crash. I've used MS Word and Google Docs a long time and never had issues with them. It's sad the first time I try using LibreOffice instead that it's buggy.
Several things here: - hopefully, I suppose the doc you've been working for 2 days shouldn't be too important. Indeed, you would have saved it at least 2 or 3 times just in case since you would have read something about the fact that LO was working differently than Google Docs - you didn't try to reproduce this and I can understand you since it may last 2 days but since you monitored RAM during 2 days, I suppose you've noted some specific actions which don't release correctly memory - you know enough about coding to write your own code editor in Rust and since Rust is a great language with a syntax similar to C/C++ and considering LO is done in C++ at about 90-95%, you certainly may help us to pinpoint the memleak you encountered! This page may interest you: https://wiki.documentfoundation.org/Development/GetInvolved but, since you know how to code, also this one: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information Anyway, we need at least a step by step process to reproduce one of the leaks you encountered because for the moment we got no start point.
It was school work. I rewrote it remembering to save frequently this time. I installed the long term support version of LibreOffice hoping it wouldn't have the bug. After using the LTS version for multiple days it seemed that the LTS version still has the same memory leak as the latest release version. I always have Task Manager open so I can monitor what my computer is doing. Anyways I decided to take the time to reproduce the bug. Through experimentation I discovered the actions causing memory to not be released. It seems that zooming and or scrolling allocate small amounts of memory that are never released. In addition selecting text causes small amounts of memory to be allocated and never released. But biggest of all I found that the combination of both selecting text and scrolling at the same time allocates large amounts of memory that are never released. By repeatedly selecting text and scrolling at the same time I am able to make the app crash due to running out of memory in under a minute. Although Rust and C/C++ are often used for the same purpose they are fundamentally very different languages. I do know the very basics of C/C++ plus, but I'm definitely unqualified to dig through a massive C++ codebase Although I have neither the time nor experience to pinpoint the bug I hope that now that I've uncovered the specific action causing it that you will be able to proceed with foreword with a fix for it.
vxs2005: thank you for the feedback telesto: would you have some time to use macOS leaks detector and give a try by scrolling + select text and zooming in/out ? Indeed, on pc Debian x86-64 with master sources updated today, I noticed nothing special with Valgrind.
@vxs2005@yahoo.com Would you mind to post About information here. Toolbar -> Help -> About. Click the copy about button.. I would like to exclude the possibility that Skia Vulkan is enabled. This might cause the leak
Here is the information: Version: 7.4.7.2 (x64) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
(In reply to vxs2005 from comment #5) > Here is the information: > Version: 7.4.7.2 (x64) / LibreOffice Community > Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 > CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: CL Since you use Skia Vulkan (so rendering with graphic card), you can try: 1) check you got last graphic driver if it's already the case 2) follow https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_(_Skia_) and disable Skia Vulkan to use Skia Raster (so it won't use GPU accelerated vector rendering) Indeed, Telesto means leaks may be due to Vulkan part. The goal is to know if they're also present with raster part.
I do have the latest drivers. After disabling Vulkan the memory leak appears to be fixed. So I guess that means either your use of the Vulkan API is bugged or AMD's drivers are buggy which wouldn't be surprising considering I recently filed a different bug report (https://bugs.chromium.org/p/chromium/issues/detail?id=1463267) caused by AMD's drivers
I must recognize I don't know what's the next step, is it a WONTFIX, a NOTOURBUG or still a LO bug if the leaks are generated by LO use of Vulkan...
Just confirming: you experienced the same issue in 7.4.7.2 with Skia/Vulkan?
Yes, this is the build: https://git.libreoffice.org/core/+log/723314e595e8007d3cf785c16538505a1c878ca5