Description: Memory not freed after PDF export Steps to Reproduce: 1. Open attachment 192460 [details] (takes a while to open, 1500 pages) 2. Open a process monitor to check memory usage 3. Save as PDF Actual Results: * Memory usage increases to from 1,5 to 4 GB (feels excessive) while exporting with ba8f4bff6015013013df652efbfaf4d9ae10c881 * The RAM usage is sticky. Close the document after export. Expected Results: Primary, free ram after export Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ba8f4bff6015013013df652efbfaf4d9ae10c881 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
On Windows with Skia/Vulkan: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 17fc445938dedb05125a6d6a5b4ce7f34ea95f59 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded After open the file: 0.6 GB After export to PDF: 0.7 GB On Windows with Skia/Raster: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 17fc445938dedb05125a6d6a5b4ce7f34ea95f59 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded After open the file: 0.5 GB After export to PDF: 0.5 GB On Windows with default: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 17fc445938dedb05125a6d6a5b4ce7f34ea95f59 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded After open the file: 0.5 GB After export to PDF: 0.5 GB
Similar to comment 1 with Windows Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4d381b54d1c598c181b4a21a8bf0db86eb4668d1 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 threaded The document is only using 295 MB in my case on export 421 MB. Drops nicely after closing the window. Different story for macOS
Tested on Linux: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d2fa44db6f8a1badece63856ee0f12db4cba9b28 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded When opened, settles at about 830 mb. When exporting, goes to 900 mb. Settles back to 880 mb afterwards. If I export again, it settles to 910 mb, but doesn't go further with subsequent exports. It does look macOS-specific.
Confirmed using Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: macOS 11.7.10; UI render: Skia/Raster; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded from ~690mb up to 3,53GB "going back" after export 3,54GB
(In reply to Dennis Roczek from comment #4) > Confirmed using > > Version: 24.2.0.3 (X86_64) / LibreOffice Community > Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 > CPU threads: 4; OS: macOS 11.7.10; UI render: Skia/Raster; VCL: osx > Locale: de-DE (de_DE.UTF-8); UI: de-DE > Calc: threaded > > from ~690mb > up to 3,53GB > "going back" after export 3,54GB missed: but even when closing the document, it still stays at 3,31GB in my case! o.O
Still present Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aaf2967d74a9a7ba2d28433e1872422ce38b6244 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
@Patrick Would be nice if you could peak into this some day, if you're interest of course. This might be very specific corner case, or making a general existing issue very visible.. No clue There are more issues with PDF export with sticky ram usage, this one is somehow macOS specific
Created attachment 195028 [details] Snapsot of Instruments app with the stack of the largest leak
(In reply to Patrick Luby (volunteer) from comment #8) > Created attachment 195028 [details] > Snapsot of Instruments app with the stack of the largest leak I connected the Instruments application to LibreOffice running from my local master build (you can also connect Instruments to nightly builds as well), opened https://bugs.documentfoundation.org/attachment.cgi?id=192460, exported to PDF from the toolbar button, and closed the document window. In attachment #195028 [details], the Allocations graph is at 3.0 GB and the lowest function call in the largest leak's stack (i.e. the selected line near the bottom right corner) is 2.85 GB. Seems like a pretty specific macOS-only memory leak so I'll look at the code tomorrow and post again when I have some news.
Just realizing: this is not happening with Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: ff2ba77f22b2e96f96f5537aec1705956b47583d CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded will do a bibisect.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2e87c644245751aea9f50faf16c4ca4d57b0c2f1 tdf#159680 fix memory leak of CTFontRef It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Dennis Roczek from comment #10) > Just realizing: this is not happening with > > > Version: 7.2.0.0.alpha1+ / LibreOffice Community > Build ID: ff2ba77f22b2e96f96f5537aec1705956b47583d > CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx > Locale: de-DE (de_DE.UTF-8); UI: en-US > Calc: threaded > > will do a bibisect. No need. This was a memory leak in macOS native code that I have already fixed.
I have committed a fix this bug. The fix should be in tomorrow's (29 June 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
(In reply to Patrick Luby (volunteer) from comment #12) > (In reply to Dennis Roczek from comment #10) > > Just realizing: this is not happening with > > > > > > Version: 7.2.0.0.alpha1+ / LibreOffice Community > > Build ID: ff2ba77f22b2e96f96f5537aec1705956b47583d > > CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx > > Locale: de-DE (de_DE.UTF-8); UI: en-US > > Calc: threaded > > > > will do a bibisect. > > No need. This was a memory leak in macOS native code that I have already > fixed. Just for the reference: the first bad commit was https://git.libreoffice.org/core/+/164d717530aff8d2581d0a2ff249f83aabb27502 I did read that too late ;-)
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/b0f047a710dd9bb69a12eeae24a116c74b42ce81 tdf#159680 fix memory leak of CTFontRef It will be available in 24.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/f18e9d5c1bf23306efb2941170decf2f002322d5 tdf#159680 fix memory leak of CTFontRef It will be available in 24.8.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.