Bug 140505 - LibO doesn't cleanup memory after document is closed
Summary: LibO doesn't cleanup memory after document is closed
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Memory
  Show dependency treegraph
 
Reported: 2021-02-18 13:05 UTC by bugzilla2
Modified: 2024-03-06 09:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bugzilla2 2021-02-18 13:05:11 UTC
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:
.
Comment 1 Buovjaga 2022-03-07 07:31:54 UTC
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.
Comment 2 bugzilla2 2022-03-07 11:01:18 UTC
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.
Comment 3 Buovjaga 2022-03-07 12:27:26 UTC
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."
Comment 4 bugzilla2 2022-04-27 16:36:19 UTC
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?
Comment 5 Buovjaga 2022-04-27 17:11:20 UTC
(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)."
Comment 6 Roman Kuznetsov 2022-09-10 12:41:48 UTC
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
Comment 7 bugzilla2 2022-09-12 09:51:49 UTC
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
Comment 8 Buovjaga 2022-09-12 15:05:27 UTC
(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.
Comment 9 bugzilla2 2022-09-13 09:05:29 UTC
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.
Comment 10 Mike Kaganski 2024-03-06 08:49:33 UTC Comment hidden (off-topic)
Comment 11 bugzilla2 2024-03-06 09:37:26 UTC
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?