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)

I repro, but why open this when bug 132536 still does not have a solution?

(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..

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.

Reproduced.

Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: cd2b5168e8ef1cb6e721bc5220421464ed723096
CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: ru-RU (ru_RU.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-21_14:56:23
Calc: threaded

Memory is still not freed after closing.

Arch Linux 64-bit
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 3231db0341baffd2547c50d36ef7c00aaa11601d
CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded
Built on 9 September 2024