Bug 114890 - MacOS: memory consumption keeps increasing when repeating the same edit/load/save operations
Summary: MacOS: memory consumption keeps increasing when repeating the same edit/load/...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha0+
Hardware: All macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Memory
  Show dependency tree / graph
 
Reported: 2018-01-07 16:51 UTC by Telesto
Modified: 2020-06-14 02:14 UTC (History)
0 users

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-01-07 16:51:55 UTC 
Description:
MacOS: memory consumption keeps increasing when repeating the same edit/load/save operations

Steps to Reproduce:
1. Open a Writer document press a few spaces to load the language stuff (memory usage will be around 125 -> Starting point. Keeps monitoring the memory usage following the steps given:
2. Add 4 additional Writer documents
3. Set a Page color -> Format -> Page -> Area -> Color (notice a bump in memory usage after applying) for all pages
4. Close and save all the 5 documents
5. Reopen them from start center
6. Insert a FontWork -> Insert FontWork to all documents
7. Close and Save
8. Do everything in reverse 
a. remove font work & save en close
b. reopen files and disable the page color -> Save and close

Actual Results:  
Memory usage keeps climbing. Memory usage will be around 260 MB for Start Center only when following the given steps

Expected Results:
I would expect it to be around 140-150 MB


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.1.0.0.alpha0+
Build ID: 184ce84226b49a1b4b693f3bb8cc8569c76d864d
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-12-18_23:53:27
Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded

I didn't see any leakage in Instrument Leak profile..


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8
Comment 1 Alex Thurgood 2018-01-08 14:43:08 UTC 
Confirming with 

Version: 6.1.0.0.alpha0+
Build ID: 5b7ec49f453c3732e2482b26bce4243eb1a10f40
CPU threads: 4; OS: Mac OS X 10.13.2; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded

Average memory occupied : 255-260 Mb
Comment 2 Telesto 2018-01-08 16:46:09 UTC 
No repro on Windows
Version: 6.1.0.0.alpha0+
Build ID: a9b202a6b7000e7af34f2a639ca207122a3968bf
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-12-26_23:10:23
Locale: nl-NL (nl_NL); Calc: CL

LibO Linux is also affected to some extend, but not climbing as fast as MacOS and seems to be limited too..
Comment 3 Telesto 2018-01-09 10:51:46 UTC 
There are more scenario's where this is happening to at least some extend; it's only hard to find a trigger causing a further build up. It does happen over time, by my own experience. But I don't have really concrete steps..

For example: I'm noticing some build up when three (empty) 200 sheet template presentation and save them. Adding a font art to one of them will increase it some more.
Comment 4 QA Administrators 2019-01-10 03:52:48 UTC Comment hidden (obsolete)
Comment 5 Luke 2020-06-14 02:14:00 UTC 
This bug seems to have been fixed - tested the given steps on macOS Catalina using the latest LibreOffice:

Version: 6.4.4.2
Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU threads: 4; OS: Mac OS X 10.15.4; UI render: default; VCL: osx; 
Locale: en-NZ (en_NZ.UTF-8); UI-Language: en-US
Calc: threaded