Download it now!
Bug 134026 - Memory after third opening 280 MB expected 130 MB
Summary: Memory after third opening 280 MB expected 130 MB
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2020-06-16 09:00 UTC by Telesto
Modified: 2020-09-12 10:16 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-06-16 09:00:11 UTC
Memory after third opening 280 MB expected 130 MB

Steps to Reproduce:
1. Open attachment 97742 [details] (bug 77519)
2. Close
3. Repeat 3x and look at memory usage for start center at the third time

Actual Results:
280 MB

Expected Results:
150 MB

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: (x64)
Build ID: a35c18aeff3b1d8f270db7e094850fb8ba1ab84a
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

not in
Version: (x64)
Build ID: 20be5cd0bdc57d812bf34a2debfe48caa51de881
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL

I hope I'm repeating myself: weldfontbox.. bug 132536
Comment 1 dante19031999 2020-06-17 03:07:31 UTC
I tried to reproduce on Windows 10 and debian with 7.0 beta 1 and could not reproduce.
- Could already been corrected (please check).
- Be more specific about your system.
- (note: I'm not a pro)
Comment 2 Buovjaga 2020-06-17 10:39:45 UTC
I repro, but why open this when bug 132536 still does not have a solution?
Comment 3 Telesto 2020-06-17 12:04:32 UTC
(In reply to Buovjaga from comment #2)
> I repro, but why open this when bug 132536 still does not have a solution?

Because I'm using the bugtracker as reminder to look at it some time; I probably forget it.. at some point. And because I'm getting slightly impatient.. 

* While testing bug I end up with 1/2 GB ram used.. with documents of 15 pages in around 15 minutes.. I can only assume.. its the font cache, it's font cache.. but never knowing for sure.. maybe another change..
* Font cache is tricky area.. Developers tend to walk around it for years. And Khaled wasn't to happy with it either (and struggled to understand how it worked).. So I assume the font cache to be a quite a thing; even for experienced developers. Which makes me even more worrisome. And I connecting this with the work of M. Stahl on tables, solve 1 problem, get 2 back. Solve two problems get 4 back.. 

Or Jmux starting to fiddle with timers, madness appears everywhere (re-resurrecting old hideous bugs etc). So I'm assuming the worst case.. until I'm proven wrong... Especially with fonts/ font measurements being cached/used on different levels. Harfbuzz Internal/ LibreOffice itself?/ the layout cache of Miklos.. all relaying on font lifetime cycles etc. Different font handling between OSes.. So enough potential to go wrong. It started already with welding the Fontbox; adding of a new special rendering; removing a few font caches..

This type of rework you ideally plan in advance to do, not something you want to resolve as side effect of welding; Ideally at the beginning of a new release, not at the point of beta2 or RC1...

And a developer delaying to look at - I assume so; can't proof, maybe looking at it in silence - it doesn't give me much confidence. I don't associate Caolan in addition with font handling in general (more the expertise of Jmux/Khaled) and/or 
developing on Windows. Caolan has tons of experience... so maybe underestimating (hope so) but I don't see it as his area of expertise (or interest?). Especially if the font cache code being broken all over the place.. So fiddle with A and B does something unexpected. Fiddle with C and D does something it shouldn't do. Fiddle with E, expect G and get Z.

I'm too pessimistic, I hope..
Comment 4 Buovjaga 2020-06-17 14:58:55 UTC
I tested with Linux 6.5 repo and indeed before the weldfontbox commit the memory use was reset after each close/open cycle. So I don't know - it seems impossible to determine at this point, if this issue is separate. It would be masked behind the remaining issue.