Description: Follow-up to https://bugs.documentfoundation.org/show_bug.cgi?id=152524 (macOS: LibreOffice crashes (gpgme / gpgmeio) on macOS 13 Ventura) While Patrick investigated that highly problematic crash it came to light that, at least on intel macs on macOS 13 Ventura, having many OpenPGP keys can lead to delays of up to a minute when opening LibreOffice. Apparently OpenPGP key details are being processed / loaded already when LibreOffice is opened as described in https://bugs.documentfoundation.org/show_bug.cgi?id=152524#c89: "I know LibreOffice loads all of your certificates sequentially so maybe I can see if we can delay loading each certificate's details until it is selected in the certificate selection dialog." If processing of OpenPGP key details can be delayed until required for an action that uses OpenPGP that would be a win for users. I set this to Minor, since on Apple Silicon with macOS 14.4.1 I am not seeing the beachball / delay when opening LibreOffice. I am unsure if that is because the problem does not occur on macOS Sonoma or if Apple Silicon has much better performance. Will have to test this some more on an old 2012 mac on which I run macOS Sonoma via OpenCoreLegacyPatcher but I am not near that mac currently. Steps to Reproduce: 1. have a few hundred key in GPG Keychain on your macOS 13 Ventura mac (unsure if intel mac is a requirement for this performance problem to show) Actual Results: Beachball / delay when opening LibreOffice. Expected Results: If the delay can be delayed (scnr) until the user interacts with OpenPGP functionality, that would improve the overall user experience. Reproducible: Sometimes User Profile Reset: No Additional Info: This is an edge case, and further investigation is needed to see if the issue is limited to macOS 13. If that is the case, spending time on this problem is probably not worth it. But that is to be discussed.
This is the mac where reproducing the delay is possible: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 71efd6046488b952f679936ea1c4a415f4989b18 CPU threads: 8; OS: macOS 13.6.6; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 193713 [details] 2024-04-16 Sample of LibreOfficeDev while hanging
(In reply to steve from comment #2) > Created attachment 193713 [details] > 2024-04-16 Sample of LibreOfficeDev while hanging Interestingly, your sample shows LibreOffice is loading all of fonts for the Font combobox in the toolbar. I don't see any GPG code in your sample so I wonder if one or more fonts are loading very slowly. If you validate all your fonts using the steps in the following comment, are there any fonts with warnings or errors? If yes, does deactivating or removing them stop or reduce the hang?: https://bugs.documentfoundation.org/show_bug.cgi?id=160644#c7
Created attachment 193732 [details] 2024-04-17 process sample 2 minor problems were found, so both fonts were removed. The hang seems to only happen after a restart. And when it has happened it does not happen on a second opening. LibreOfficeDev shows as "Not responding" in Activity Monitor when the hang happens. Attaching another process sample.
(In reply to steve from comment #4) > Created attachment 193732 [details] > 2024-04-17 process sample > > 2 minor problems were found, so both fonts were removed. > > The hang seems to only happen after a restart. And when it has happened it > does not happen on a second opening. LibreOfficeDev shows as "Not > responding" in Activity Monitor when the hang happens. > > Attaching another process sample. Your latest sample is hanging in the same place: loading fonts. It makes sense that this hang only happens on the first launch of LibreOffice after rebooting. The reason is that once a font is first loaded, macOS keeps it cached in memory so that LibreOffice and any other applications can use the font quickly. But for some reason, one or more of your fonts are very slow to load. The problem is how do we identify which font? Do you have any non-system fonts installed in the "My Fonts" sidebar item in the Font Book application? Does deactivating those fonts and rebooting stop the hang?
(In reply to Patrick Luby (volunteer) from comment #5) > But for some reason, one or more of your fonts are very slow to load. The > problem is how do we identify which font? Do you have any non-system fonts > installed in the "My Fonts" sidebar item in the Font Book application? Does > deactivating those fonts and rebooting stop the hang? After thinking a bit more about this, I think the problem is likely an unusually large font file. Both samples show a memcpy() at the bottom of the main thread so I am guessing that the size of the glyph table that is being copied from the font file is very large. So, before you spend any time rebooting, can you look at your fonts in the My Fonts section of the Font Book application. Right-click on each font and select the "Show in Finder" popup menu item to see the file size of the font in the Finder. For comparison, one of the largest font files bundled with macOS is the Apple Color Emoji font file and, at least on macOS Sonoma 14.4.1, it shows 188.3 MB in size in the Finder. So if you see a similar sized or larger font file, I can try installing that font on my machine and see if I can reproduce this bug.
adjusted title to reflect correct problem
Created attachment 193750 [details] 2024-04-19 process sample Disabled all fonts in the "My Fonts" section of Font Book app and restarted the mac. Adding another process sample of LO still hanging on launch. I opened the fonts in finder and sorted by size. The largest font is songti (macOS font) which I cannot deactivate or delete. This seems to be true for the largest fonts in file size. From the custom fonts the sf-fonts are the largest. This seems a hard to investigate problem. Not sure if it is worth further investigating. I can not reproduce on an Apple Silicon mac. If you have other ideas, please let me know and happy to try, if not, also fine to close this bug.
(In reply to steve from comment #8) > This seems a hard to investigate problem. Not sure if it is worth further > investigating. I can not reproduce on an Apple Silicon mac. If you have > other ideas, please let me know and happy to try, if not, also fine to close > this bug. I cannot reproduce this bug either on macOS 14.4.1 Sonoma on my Silicon MacBook Pro. Your latest sample is identical to the previous two samples: macOS is stuck copy bytes from a font file. To me, that seems really unusual as the font has been loaded, we've already allocated memory for the copy of the font table, but your samples show LibreOffice is stuck in a memcpy(). I see the com.apple.NSEventThread thread further down in your sample in an apparent loop that is allocating memory. That thread is not LibreOffice code, however, and is a thread created by the macOS code so maybe that is the ultimate cause of the hang. But, since both the stuck thread and the com.apple.NSEventThread thread are internal macOS code, I'll close as "notourbug".