Description: I have a ODT file that is causing a repeatable crash with 25.8 RC1. Trying to recover the file repeats the crash. The macOS crash log is attached: Steps to Reproduce: 1. Load custom.odt 2. Crash 3. Actual Results: Crash Expected Results: Load Reproducible: Always User Profile Reset: Yes Additional Info: I use this file as a template for ODT files pandoc produce.
Created attachment 201743 [details] File causing crash
Created attachment 201744 [details] maccOS crash log
The same document works for me in 25.2.4
Not reproducible in Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 20667acbca5df17771a3581632a672d5db4e751b CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
I can reproduce it on mac though with a local build
Reproduced with Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 10850b9ea91807c4f8464e42fee7f33b7c389a77 CPU threads: 8; OS: macOS 15.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_ES.UTF-8); UI: en-US Calc: threaded with a non signed build
Created attachment 201751 [details] simplified document
Regression introduced by commit 477689c58d842c718940c568616890179f5aac06 [log] author Xisco Fauli <xiscofauli@libreoffice.org> Tue Apr 29 13:21:44 2025 +0200 committer Xisco Fauli <xiscofauli@libreoffice.org> Tue Apr 29 15:05:45 2025 +0200 tree 95c924bb3e385817ab3a9a151e042a4f828a174f parent b4965d0a7875384d1fedc7d43762c94b30e5e90f [diff] harfbuzz: upgrade to 11.2.0
Issue reported on harfbuzz's side: https://github.com/harfbuzz/harfbuzz/issues/5386
(In reply to Xisco Faulí from comment #9) > Issue reported on harfbuzz's side: > https://github.com/harfbuzz/harfbuzz/issues/5386 @Patrick, I thought you might be interested in this issue since it's a mix of the upgrade to 11.2.0 and your patch for tdf#159529: https://git.libreoffice.org/core/commit/af47a78e11d4819bb4b1ae1a1277babd10d815b7
(In reply to Xisco Faulí from comment #11) > (In reply to Xisco Faulí from comment #9) > > Issue reported on harfbuzz's side: > > https://github.com/harfbuzz/harfbuzz/issues/5386 > > @Patrick, I thought you might be interested in this issue since it's a mix > of the upgrade to 11.2.0 and your patch for tdf#159529: > https://git.libreoffice.org/core/commit/ > af47a78e11d4819bb4b1ae1a1277babd10d815b7 I got a chuckle with the "that patch dangerously modifies HarfBuzz internals". Yes, because HarfBuzz catches every font's glyphs in memory which, on macOS, means several gigabytes of data due to the large size of emoji and CJK fonts. This makes HarfBuzz fast but overwhelms your average Mac. HarfBuzz used to have a flushable cache for a font's glyphs to that automatically repopulate its glyph cache when used again. So I am guessing HarfBuzz now just expects "font glyphs remain in memory for the life of the font". Bad idea on macOS IMHO but maybe Windows and Linux fonts aren't very large so the HarfBuzz developers don't see the memory usage as a problem. Anyway, I think we have 2 choices here: 1. Revert my patch and watch memory usage explode for *all* macOS users (like an extra GB or two) 2. I must write another "dangerous" modification to HarfBuzz to force a font to repopulate its glyph cache after it has been flushed. Thoughts?
(In reply to Patrick (volunteer) from comment #12) > Anyway, I think we have 2 choices here: > 1. Revert my patch and watch memory usage explode for *all* macOS users > (like an extra GB or two) > 2. I must write another "dangerous" modification to HarfBuzz to force a font > to repopulate its glyph cache after it has been flushed. It is kind of ironic that the developer who caused the HarfBuzz memory problems on macOS (and which I have been trying to clean up) thinks my patch is dangerous. Yet, HarfBuzz has no public API for flushing a font's glyph cache and since @Khaled's code holds onto a HarfBuzz font instance of every system font until LibreOffice is quit, holding all those font instances without flushing their glyph caches is not a reasonable approach on macOS. Sure, I could rewrite @Khaled's vcl implementation and continually delete a HarfBuzz font immediately after accessing its glyphs but I really don't have any spare time to implement font swapping in vcl. So it looks like another "dangerous" patch is our only option.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/93548628d2a7cd44195193620a2a43dbeda3f79b tdf#167455: sw_odfimport: Add test It will be available in 25.2.6. 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.
Created attachment 201760 [details] Instruments memory usage profile with https://gerrit.libreoffice.org/c/core/+/187736 I have submitted the following fix for this bug: https://gerrit.libreoffice.org/c/core/+/187736 Interestingly, it also lowers memory usage due to cached font tables significantly. With the above fix, memory usage due to cached font tables is around 180 MB after scrolling through the entire font listbox. Previously, in my original patch that caused this bug, memory usage was 550 MB. Without my original patch or the above fix, memory was 750 MB. So, the above fix drops memory usage by nearly 400 MB vs my original patch and 600 MB without any of my patches. I admit that I am suprised how much cached memory my original patch missed.
Found a better solution than the one I linked to in comment #15: https://gerrit.libreoffice.org/c/core/+/187761 It still needs to be reviewed. But I will post steps for testing once it has been committed.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d7effccb89fccf42b2942aefec292670f3533130 tdf#167455: sw_odfimport: Add test It will be available in 26.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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/79dc0ebf6a7dd2757dcb3efc01d57e860816828c tdf#167455: sw_odfimport: Add test It will be available in 25.8.0.2. 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.
My fix has been committed and the fix should be in tomorrow's (13 July 2025) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app