Description: If you open the LibreOffice settings in version 25.2 on an Apple Silicon Mac, the program freezes. It can only be closed by terminating the program-task via the activity monitor. Furthermore, the menubar on macOS becomes unresponsive. This does not constantly happen, but very frequently. Occasionally, you can click on the various items on the left side of the settings-screen without the right side of the screen getting updated. The problem occurred no matter if I had installed LibreOffice via Homebrew or by downloading and installing the dmg-file. Steps to Reproduce: 1. Open the settings (does not matter if via CMD+Comma or via the menubar etc.) 2. Click on several entries / options on the right side 3. Click on several entries / options on the left side 4. Try to apply settings / options 5. Screen sometimes leads to crashes, sometimes works just fine Actual Results: Program freezes. Can only be terminated via activity-monitor. Expected Results: Change settings and allow me to save them. Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.0.3 (AARCH64) / LibreOffice Community Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069 CPU threads: 14; OS: macOS 15.3; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded
It seems as if the problem has (also) something to do with changing the appearance of LibreOffice. I have reset my user profile just now and LibreOffice used the dark appearance (my system's default). When switching to the light appearance, the app does not update and when closing and restarting LibreOffice, the settings are problematic and are causing freezes.
No repro with Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 7e1282affdb4e132a6329f378d6379155968b689 CPU threads: 8; OS: macOS 15.2; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded (master build from 18/02/2025)
When I write no repro, I mean with respect to unfolding entries in the user preferences panel. I haven't tried changing themes.
Sascha, thanks for reporting this issue, which I hereby confirm and set to NEW. Opening LO Settings freezes the app. Clicking "OK" or "Cancel" buttons does nothing. They are unresponsive for some time. This is not always reproducible but happened several times. After a few seconds app unfreezes and can be interacted with again. It seems easiest to reproduce when launching LO and quickly opening the settings. Something is keeping LO busy. During the hang, CPU goes to ~110 %. Once CPU normalises, LO can again be interacted with. I am a bit confused as now I am no longer able to reproduce while I just reproduced 4-5 times. I cleared unavailable files from start center. Created a new file, saved that to desktop, removed file and indeed the issue is back. So my theory is this hang is somehow related to unavailable files in start center. Version: 25.2.0.3 (AARCH64) / LibreOffice Community Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069 CPU threads: 12; OS: macOS 15.3.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Hmm, sorry - even with an unavailable file the hang is not always reproducible. Wish I had a stronger repro case to offer :( Could it be that the unavailable file has to be on top left? I am again able to reproduce.
Wondering whether bug 165202 might be related. If so, then hope for a solution lies in 25.2.1.
Alex: could you try to repro with the steps outlined? Have an unavailable file in top left position of start center file listing and then right after launching LO open settings. If the issue is addressed in 25.2.1 should the fix also be in main? The link bug lacks tracking flags for fixed versions. But for me main build from today also has the freeze (temporary) resolves itself after a few seconds.
(In reply to steve from comment #7) > Alex: could you try to repro with the steps outlined? Have an unavailable > file in top left position of start center file listing and then right after > launching LO open settings. > > If the issue is addressed in 25.2.1 should the fix also be in main? The link > bug lacks tracking flags for fixed versions. But for me main build from > today also has the freeze (temporary) resolves itself after a few seconds. Hi Steve, I can't reproduce this with Version: 25.2.0.3 (AARCH64) / LibreOffice Community Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069 CPU threads: 8; OS: macOS 15.3.1; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded I removed all recently used files from the LO StartCenter. Restarted LO. Created a test Writer file and saved to Downloads. Shut down LO, removed the LO icon from the Dock, then deleted the file. Restarted LO, then Preferences. I could navigate through the options without issue. No freeze, hang or crash for me.
(In reply to Alex Thurgood from comment #8) Similarly, couldn't reproduce this either using the single, temporarily available file in the StartCenter procedure with: Version: 25.2.1.2 (AARCH64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 8; OS: macOS 15.3.1; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded Sorry I can't be of more help.
Thanks for testing. I notice that while I reproduced with Skia/Metal you are running UI render: Skia/Raster Could you retry with Skia/Metal?
*** Bug 165460 has been marked as a duplicate of this bug. ***
Hmm, still no repro I'm afraid with Version: 25.2.1.2 (AARCH64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 8; OS: macOS 15.3.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded Note that I'm using the Light theme in the OS settings.
(In reply to Alex Thurgood from comment #12) > > Note that I'm using the Light theme in the OS settings. Also, not reproduced with: Version: 25.2.1.2 (AARCH64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 8; OS: macOS 15.3.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded when using system Dark theme. My LO icon set is Elementary. Should I be using a different one ?
Thanks for going the extra mile with your testing. I don't think it is icon theme related as they don't really play a role in the Settings (aka Preferences). Using "Automatic (Sukapura (SVG + dark))". This may be coincidence but I was unabel to trigger the hang. Then changed "Appearance > Document background" color to any other than automatic and on re-open I get the settings hang and while I can navigate settings in the left panel the right side panel stays blank entirely.
Pressed Save too soon: please try quickly switching settings tabs via the left side menu and see if you get stuck then.
(In reply to steve from comment #15) > Pressed Save too soon: please try quickly switching settings tabs via the > left side menu and see if you get stuck then. I cannot reproduce this in the 24 February 2025 nightly build. Is is possible to get an Activity Monitor sample (assuming you see the "Autosave" dialog). Or, it it does a crash with no dialog, can you launch /Applications/Utilities/Console from the Finder, click on Crash Reports, and see if there are any recent "soffice" crash logs?: Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: f6944d251f6eb4ad2bcf6cee6027a83e44d72364 CPU threads: 8; OS: macOS 15.3.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
Lowering the importance. It seems the issue is difficult to reproduce, isn't it ?
OK. To me it looks like this bug hits some people but not others so I am assuming that some preference is set to a non-default value triggers this bug. @steve has been able to confirm this but no one else so if anyone out there can reproduce this bug easily, let us know. I can post steps for using the Activity Monitor application bundled with macOS to get a snapshot of what LibreOffice code is running during a hang.
Unable to reproduce on first attempt. Second attempt LO Settings hang. Steps were with removed file at top left position in start center (unsure if that matters) and very quickly opening settings after launching LO. Took - process sample (1 year): https://bin.disroot.org/?00345120ad2167cd#ARLeyPs1bbJX5EMZbi96SJQ6uAtAHg25QTN73y9B3bSt - spin dump (1 year): https://bin.disroot.org/?0d4ac5dfaadb67c9#Ak9iHkDKpm73Ps452duEetiMXuoohYFxRiSS8vmQwzqg Hope those are useful.
The good news is that your samples look pretty much the same as the spin dump in tdf#165505. All of the samples seem to be stuck in some macOS low-level window handling functions. LibreOffice is not calling those functions directly. Instead, they are running a macOS system timer that are fired when LibreOffice waits for the next macOS event to process. So I wonder if the dialog is stuck in a infinite repainting loop? Not sure how to troubleshoot this yet.
I could help with identifying the cause if that would be useful to you. For now, I’ve installed an older version to continue working, but I’d be willing to uninstall it and reinstall the problematic version if needed. I would just need clear instructions on how to generate the Activity Monitor sample and any other necessary diagnostics. When I reported the bug, I was able to reproduce the issue consistently. Before and after updating from the old to the new version, I also had files in the Start Center history, and one file was pinned there. I consider this bug quite serious. In my opinion, downgrading its priority is unjustified. Anyone affected by this issue is essentially unable to change their settings and is forced to downgrade to an older version.
*** Bug 165505 has been marked as a duplicate of this bug. ***
(In reply to Sascha Krämer from comment #21) > I could help with identifying the cause if that would be useful to you. For > now, I’ve installed an older version to continue working, but I’d be willing > to uninstall it and reinstall the problematic version if needed. No need for that right now. Now that we have samples from @steve and tdf#165505, I think I have an idea what might be the root cause. When we find a fix, you'll be able to test it using a nightly build which is installed as LibreOfficeDev so that you won't need to uninstall your current version of LibreOffice. From what I can see, the bug only occurs when using Skia/Metal (i.e. the default drawing option). Using the non-default drawing option (Skia/Raster and Skia disabled) doesn't appear to the trigger the bug. So if Skia/Metal is the cause, my first guess is that LibreOffice or Google's Skia code is somehow repainting that window in a near infinite loop. Since the bug doesn't occur for you with an older version, I plan on looking through any Skia/Metal code changes in LibreOffice 25.2 and see if any of those changes might trigger excessive window repainting. I'll post again when I have any news.
@steve: Can you reproduce this bug in today's nightly master build? I ask because I can reproduce the bug in my local master build by pressing and holding the Command-, keys. This opens tens of Options dialogs stacked on top of each other and the topmost dialog is completely black. I was able to connect the Instruments application and run a Time Profile while LibreOffice was in this state and most of the time spent in LibreOffice was in the CA::Transaction functions like in your samples. I'll post a snapshot of Instruments in a few minutes but I suspect that these timeconsuming CA::Transaction functions are the macOS functions that Skia uses to flush drawing to the screen. So, to summarize, I think flushing to the screen with Skia/Metal is significantly slower in Skia m130 compared to Skia m116.
Created attachment 199537 [details] Instruments snapshot after opening tens of Options dialogs by presing and holding Command-,
Found the change that caused the bug I see in comment #24. It was the following commit which caused the Skia flushing timer to never be called. Surprisingly, it had nothing to do with the Skia version change in LibreOffice 25.2. Instead, it LibreOffice's internal idle job scheduler bug. commit 3e0a2239e977a2d6f5252b2412378e02dde3a8b8 Author: Mike Kaganski <mike.kaganski@collabora.com> Date: Wed Mar 13 10:21:32 2024 +0500 Introduce a guard to delay processing of idles I should be able to fix push a fix for this bug tomorrow. Then, if @steve can reproduce this bug in a master nightly build, I will commit the fix and we can see if the next master nightly build behaves differently.
(In reply to Patrick (volunteer) from comment #26) > I should be able to fix push a fix for this bug tomorrow. Then, if @steve > can reproduce this bug in a master nightly build, I will commit the fix and > we can see if the next master nightly build behaves differently. Interestingly, commit 3e0a2239e977a2d6f5252b2412378e02dde3a8b8 isn't the root cause of the bug. I think the root cause is that Skia/Metal with Skia m130 is a lot slower than with Skia m116 and its backing up LibreOffice's event processing.
(I posted one of the duplicates) I tried to revert to 24.8.5 (newly released) and I also see a substantial hang (ironically I tried to enable software-only rendering with skia), I had to wait for > 5 minutes to accept my change. Even with software skia options are very laggy. It makes it really hard to try to find which setting could alleviate this. I'm not sure if this aligns with Patrick's detailed QA (thank you for your work on this, this is a major issue IMO).
I reverted to 24.8.1 and Options work fast and fine (software rendering still on), so one question is was the skia change from 25 backported to 24.8.5? This is 100% reliable here on my M2. ...and 24.8.4.2 also works fine (i tried with and without software skia)... So I will try to disable skia completely, and perhaps an Intel build via rosetta may show a different behaviour? BTW the view preferences are saved at /Users/ian/Library/Application Support/LibreOffice/4/user/registrymodifications.xcu -- if i edit this file when LO is closed it should pick the changes up?
<item oor:path="/org.openoffice.Office.Common/VCL"><prop oor:name="UseSkia" oor:op="fuse"><value>false</value></prop></item> This means skia is disabled? I still see hanging options dialog when skia is disabled (25.2.1, I imagine I'll see the same with 24.8.5).
(In reply to Iandol from comment #30) > <item oor:path="/org.openoffice.Office.Common/VCL"><prop oor:name="UseSkia" > oor:op="fuse"><value>false</value></prop></item> > > This means skia is disabled? I still see hanging options dialog when skia is > disabled (25.2.1, I imagine I'll see the same with 24.8.5). Yes. That looks correct. I do have a Skia fix in process so let's see if that fixes Skia and then, if Skia disabled has it's own set of problems, I can investigate that next. FWIW, some of the code in the patch I hope to commit later today does affect Skia disabled as well as Skia. If you or @steve can reproduce this bug in today's master nightly build. Then we can test my fix faster (changes to 25.2 branch require more approvals before they show up in a nightly build). If you reproduce the bug in today's master nightly build, then tomorrow's nightly build should have a fix. If you can do that, today's (01 March 2025) nightly master builds are here. 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
I forgot to post a link to the patch if anyone wants to track its progress: https://gerrit.libreoffice.org/c/core/+/182380 I need to do a little more testing and write the commit comment. But one unexpected improvement in my patch is that live resizing a window is noticeably smoother even with Skia disabled. It's still not perfect, but it is definitely less jumpy.
(In reply to Iandol from comment #29) > I reverted to 24.8.1 and Options work fast and fine (software rendering > still on), so one question is was the skia change from 25 backported to > 24.8.5? This is 100% reliable here on my M2. > > ...and 24.8.4.2 also works fine (i tried with and without software skia)... I can confirm that commit 3e0a2239e977a2d6f5252b2412378e02dde3a8b8 is in the 24.8 branch. Not sure which release it was first included, but if my fix works, I'll remember to backport to the fix to the 24.8 branch.
Hi Patrick, I can confirm the nightly build still has the hang in options Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: a91494780bb59afe8c971003e6b809f1e66df050 CPU threads: 8; OS: macOS 15.4; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0ed6480f563c0f7f5601fb2045c5be2bafd226db tdf#165277 On macOS, only delay priorities lower than POST_PAINT It will be available in 25.8.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 Iandol from comment #34) > Hi Patrick, I can confirm the nightly build still has the hang in options That is excellent news. So I have committed my fix. and it should be in tomorrow morning's (02 March 2025). If you can install that tomorrow and confirm if the bug is fixed for you (or not), I can then submit the fix for the next LibreOffice 24.8 and 25.2 releases. Just to safe, I'll repeat the steps to install the master nightly build in case any other users want to try out tomorrow's nightly master build: 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
Wow, the options dialog is working perfectly, no lag, no observable CPU spikes. Amazing work (deducing the problem in a massive codebase from a couple of spindumps, fixing and pushing all in a week) and thank you for the fix. Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 27d027e5704d15639b4b06653a1ee68e8d1c5b0b CPU threads: 8; OS: macOS 15.4; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Excellent! I will start the process to get the fix into the LibreOffice 24.8 and 25.2 releases. Many thanks for testing this. While I'd like to attribute the fix to genius, the reality is that sometimes I get lucky. I still don't know why the samples looked familiar to me. The funny thing is that when I initially looked at the samples, it appeared that LibreOffice was constantly drawing to the screen when, in reality, it wasn't drawing to the screen at all. This drawing using the GPU stuff is still magic to me. Kind of like a race car: very fussy but when it works, it's fast.
Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 9b4dac8bf180f3fd5441b447a60439fb258854d4 CPU threads: 12; OS: macOS 15.3.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Works perfectly with and without skia. Thanks for the super-quick turnaround and addressing this huge annoyance.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/f3b377932ccb91463786c0e525dd6fc7406af9fc tdf#165277 On macOS, only delay priorities lower than POST_PAINT It will be available in 25.2.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/e98ff952bf8712410b204623c215fbcc19ddd473 tdf#165277 On macOS, only delay priorities lower than POST_PAINT It will be available in 24.8.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.
I would volunteer to test the daily build, but on the ftp-server (/daily/libreoffice-24-8/) there is no Apple-Silicon-Version (aarch64), it seems...
(In reply to Sascha Krämer from comment #42) > I would volunteer to test the daily build, but on the ftp-server > (/daily/libreoffice-24-8/) there is no Apple-Silicon-Version (aarch64), it > seems... Wrong server. The fix is only in the master branch right now. To download the nightly master build, use the following steps: 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
(In reply to Patrick (volunteer) from comment #43) > (In reply to Sascha Krämer from comment #42) > > I would volunteer to test the daily build, but on the ftp-server > > (/daily/libreoffice-24-8/) there is no Apple-Silicon-Version (aarch64), it > > seems... > > Wrong server. The fix is only in the master branch right now. To download > the nightly master build, use the following steps: > > https://dev-builds.libreoffice.org/daily/master/current.html > Hi Patrick, Thank you. I downloaded the below-mentioned version. With this version, the settings-menu works just fine. If I am supposed to test anything else, feel free to point me into the right direction. Thank you all for caring and solving this bug so quickly! Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 8e2effa8955db4dc4b31145fbb14b53636b32186 CPU threads: 14; OS: macOS 15.3.1; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded
PS: I tried it with and without documents in the StartCenter. I also pinned a document to the StartCenter and everything was fine.
Thanks for testing. So far it seems that this bug appears the most in the Options dialog (i.e. LibreOffice > Preferences menu item). The fix should be in the updating LibreOffice 25.2.2 release which IIRC is planned for release in the last week of March 2025. The Mac App Store will also get the fix in LibreOffice 24.8.6 soon after that I hope.
*** Bug 165358 has been marked as a duplicate of this bug. ***
*** Bug 165554 has been marked as a duplicate of this bug. ***
*** Bug 165734 has been marked as a duplicate of this bug. ***
*** Bug 165747 has been marked as a duplicate of this bug. ***
*** Bug 165978 has been marked as a duplicate of this bug. ***