Description: LibreOffice doesn't release memory after closing a document. Steps to Reproduce: 1. Close all LibO Windows and quickstarter 2. Create an new empty writer document and look at the memory sage of LibO in taskmanager 3. Open the biggest odt-file you can find and remember the RAM usage of libreoffice in taskmanager 4. Close all documents but not the quickstarter Actual Results: the memory usage of LibO remains on whatever the peak was. LibO doesn't free up unused memory ever. You can let the PC sitt for several hours, and it will still consume as much memory as if both documents are still open. In my case, LibO used more than 7GB even though no document was edited for hours. Expected Results: LibreOffice should free up memory when the document who allocated the memory is closed. Reproducible: Always User Profile Reset: No Additional Info: .
There have been many similar reports over the years by certain reporters. I see you are running 7.0. There have been many performance optimisations since then. Could you try again with 7.3? Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
The Problem still exists in 7.3.1.2. Opened a Document, memory goes up to 1.13GB. Close the Document and RAM-Usage doesn't get smaller. Even after 2 hours no decrease.
See here for similar ones closed as notabug: https://bugs.documentfoundation.org/buglist.cgi?list_id=1427545&query_format=advanced&resolution=NOTABUG&short_desc=memory%20clos&short_desc_type=allwordssubstr For example bug 135010 comment 11: "The problem appears to be that we do a huge number of small allocations, which means glibc has to allocate a lot of system memory, then when freeing that memory gets fragmented, so there's apparently no good way to return it to the system. I don't think there's a reasonably simple solution to this."
I'm not a developer, so I have no idea what glibc is aso :D For me it sounds like: "yes, we do have a problem there, but we can't fix it", which of course isn't what someone wants to hear :D So, if the memory usage can't be "shrinked" or "defragmented" during runtime, what about restarting the quickstarter if a given memory limit is exceed and there are no open documents for an other given time? For example: I open a document and memory usage of soffice.bin goes up to 1.2GB. I close the document (soffice.bin still consumes 1.2GB) The quickstarter sees that RAM Usage is above 500MB and that there are no open documents and the process is "idling" for 5 minutes, so the quickstarter starts itself new. That way, the RAM-Usage goes down. Of course that doesn't help anything for people that have documents open the whole day, but for some that maybe could be helpful?
(In reply to bugzilla2 from comment #4) > I'm not a developer, so I have no idea what glibc is aso :D https://en.wikipedia.org/wiki/Glibc "The GNU C Library, commonly known as glibc, is the GNU Project's implementation of the C standard library. Despite its name, it now also directly supports C++ (and, indirectly, other programming languages)."
I tried to open my own example ODS with 180mb size, LO Calc took over 6 Gb of memory. After the file closing LO became to eat only 140 mb of memory Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 88d7aa8ab79b1197191b5eb24a3b67d313797026 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded Let's close it as WFM
Reopened, because (sadly) the bug is not fixed yet. But I have to be more precise on the steps to reproduce from Comment #1, because to have LibO consuming that much RAM on an average odt, you have to use languagetool extension. Thus adds the java dependency. So maybe the bug is fixed (or never happened) if Java is not in use, but if it is, we have the problems described in #1. Retested with most recent master: Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4ca5c021c91680f1a5df47225d9cb0d41c0a8637 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: de-AT (de_AT); UI: de-DE Calc: CL threaded
(In reply to bugzilla2 from comment #7) > Reopened, because (sadly) the bug is not fixed yet. > > But I have to be more precise on the steps to reproduce from Comment #1, > because to have LibO consuming that much RAM on an average odt, you have to > use languagetool extension. Thus adds the java dependency. So maybe the bug > is fixed (or never happened) if Java is not in use, but if it is, we have > the problems described in #1. Can you test without Languagetool, then? Should be easy as you already have a master build with its own user profile.
First: I'm not sure why I should test without LanguageTool. Its a bit like going to the car-mechanic because the Car's Battery loses Power since the radio is installed, and the mechanic says: "Test if the problem persists without the radio". Second: Anyway, I did the test, and as it seems, even without LanguageTool and JVM (both deactivated), LibO doesn't release memory very well. Here the test-results: StartCenter alone (Clean, without any previously opened Document) -> 90MB StartCenter and two big Documents open -> 753MB (and growing, didn't want to wait for it to settle) StartCenter alone (after closing all Documents) -> 402MB PS: Normally I'd test with Quickstarter instead of StartCenter (because one usually doesn't let StartCenter open the whole day) but that would interfere with my Production System (7.3). And no, all other LibO Instances (including quickstarter) were closed during the test.
(In reply to bugzilla2 from comment #9) > First: > I'm not sure why I should test without LanguageTool. Its a bit like going to > the car-mechanic because the Car's Battery loses Power since the radio is > installed, and the mechanic says: "Test if the problem persists without the > radio". No, it's a bit like being asked to help others diagnose what specifically sauses your issue, and then act as if you know better what bits of information others need. But - your call. Good luck.
First of all, I retested the issue with LibO 7.6.5: Open document -> 4.2GB Close document -> still 4.2GB So, the problem still exists. Second: As we have already noticed before, this bug mainly arises with addons using Java. So, if I shall test the problem without LanguageTool, I'd need another Java based Extension to test with. Problem is, I don't know any other addon for LibO that uses Java. Anyone an idea which one I could use for that?