Description: When I try to use LibreOffice with the Mac's onscreen keyboard enabled, LibreOffice may run for a moment or two but soon (usually within a minute) exhibits the Spinning Beach Ball of Death. Once in a while (maybe 10%) it will give me a crash report, but it usually hangs and forces me to Force Quit the application. If I close the onscreen keyboard and relaunch LibreOffice, it will run indefinitely, allowing me to edit, change fonts/styles, save/load documents, everything I expect to be able to do but if I turn the onscreen keyboard back on, LibreOffice hangs within less than a minute. This happens consistently with the Writer module. I have not tried the other modules (e.g. Calc). Steps to Reproduce: 1. Make sure the onscreen keyboard is not enabled. (System Preferences -> Accessibility -> Keyboard -> Viewer -> Enable Accessibility Keyboard (uncheck the box and select "OK" if necessary)). Leave the Keyboard pane enabled. 2. Open LibreOffice.app and either create a new Writer document or open an existing ODT document 3. Work on the document -- edit it, change fonts/styles, save it, access the Help functions in the menu, etc. See "Expected Results" 4. Enable the onscreen keyboard by checking "Enable Accessibility Keyboard" in the Keyboard panel 5. Work on the document from step 3. (You can also close LO after step 3 and relaunch it after turning on the onscreen keyboard. The results are the same.) You can use either the Mac's built-in keyboard or the onscreen keyboard. See "Actual Results." Actual Results: The app freezes, showing the "Spinning Beach Ball of Death" anytime LibreOffice is in focus and forcing me to Force Quit the program. In a few cases (maybe 10%) LO crashes and generates a crash report; I don't have any commonality as to when it hangs and when it crashes. Expected Results: The app behaves normally, allowing you to create, load, edit and save documents. Reproducible: Always User Profile Reset: Yes Additional Info: This happened after I deleted and reinstalled the app (several times) and IIRC it happened in safe mode after I reset to factory defaults and started with a new profile. Version: 7.2.6.2 / LibreOffice Community Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Unfortunately, LibreOffice is known not to work correctly with many of Apple's Accessibility tools (and even 3rd party tools). As you have pointed out, activating the onscreen keyboard causes LO to crash. This is unsurprising. LO on macOS has never kept up with Apple's changes to the APIs used to provide accessibility interfacing. Unfortunately, there is very little that is likely to happen here unless either a volunteer with lots of free time on their hands can come and revisit the whole LO accessibility code, or else someone with deep pockets has the money to finance the development. I have just tested this on 7.2.6.2 and was about to comment that it appeared to be working OK, but then I activated a LO dialog (the About dialog), and boom ! instant hang. Oh well, confirming.
Created attachment 179783 [details] Apple stack trace on hang Enclosing a stack trace when LO hangs after activating the virtual onscreen keyboard and a dialog is displayed (in this case the LO About dialog).
*** Bug 152452 has been marked as a duplicate of this bug. ***
No repro Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8635c9aa8c6f1078a9e220076d5a08daf30077e8 CPU threads: 8; OS: Mac OS X 12.3.1; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
(In reply to Telesto from comment #4) > No repro > Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 8635c9aa8c6f1078a9e220076d5a08daf30077e8 > CPU threads: 8; OS: Mac OS X 12.3.1; UI render: Skia/Metal; VCL: osx > Locale: nl-NL (nl_NL.UTF-8); UI: en-US > Calc: threaded I get a hard crash with Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: ad387d5b984c6666906505d25685065f710ed55d CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded Let me try the very latest 7.6 dev build and see.
Still crashing on Arm : Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 17a8cb1573c5b75e5b7a6c480e09c681edcc26c0 CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
Created attachment 184321 [details] Apple Crash Trace with LO7.6alpha
(In reply to Alex Thurgood from comment #6) > Still crashing on Arm : > > Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community > Build ID: 17a8cb1573c5b75e5b7a6c480e09c681edcc26c0 > CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx > Locale: fr-FR (fr_FR.UTF-8); UI: en-US > Calc: threaded That's master build from 22/12/2022.
I can't reproduce, I can't confirm the issue in question. No crash. Tested latest Pre-Release, Release Candidate version 7.4.4 RC1 (2022-12-21): Version: 7.4.4.1 / LibreOffice Community Build ID: 988f4a351a6fa8cf4bdf2bdc873ca12cf8cbe625 CPU threads: 10; OS: Mac OS X 13.1; UI render: default; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Tested latest daily master version (2022-12-22): Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 8635c9aa8c6f1078a9e220076d5a08daf30077e8 CPU threads: 10; OS: Mac OS X 13.1; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded % uname -m arm64 % machine arm64e % sw_vers ProductName: macOS ProductVersion: 13.1 BuildVersion: 22C65 % sw_vers -ProductName macOS % sw_vers -ProductVersion 13.1 % sw_vers -BuildVersion 22C65
(In reply to Sierk Bornemann from comment #9) Hi Sierk, > I can't reproduce, I can't confirm the issue in question. No crash. > CPU threads: 10; OS: Mac OS X 13.1; UI render: Skia/Metal; VCL: osx I thought that this might be a difference between our two configs (I had Skia rendering disabled), but I activated Skia rendering, and it still crashes as soon as I click on any key of the virtual onscreen keyboard. The only other immediate difference that I can see is that I'm on 13.0.1 with my Macbook Pro, and you've already moved to 13.1 Very strange. % uname -m arm64 % machine arm64e % sw_vers ProductName: macOS ProductVersion: 13.0.1 BuildVersion: 22A400
I think I know what is causing this bug. The stack trace in attachment 179783 [details] is caused by issue 148435 but attachment 184321 [details] looks like a real bug in the LibreOffice accessibility code. The trigger for this bug is that you have to using macOS accessibility (or some tool that uses it). Is it possible to upload another stack trace with a recent nightly build?
Created attachment 184679 [details] Apple Crash Trace with master build from 15/01/2023 Master build tested from buildbot https://dev-builds.libreoffice.org/daily/master/MacOSX-aarch64@tb92-TDF/current/ with 15/01/2023 Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: d50eca2a30bdabdc1735c590d6ec1913c6dd22fd CPU threads: 8; OS: Mac OS X 13.0.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
I can reproduce this bug in the latest nightly build and in my local build. Note: I had to rebuild my local build without debug enabled before I could reproduce the bug. It appears to me that a string is getting deleted (presumably by another thread) while LibreOffice's accessibility code is still using the same string. Adding a SolarMutexGuard at the beginning of the accessibility function where the crash occurs stops the crashing. So, I think the problem is that many of the accessibility calls do not lock the application lock. I will go through all of the standard macOS accessibility functions that LibreOffice has implemented and add SolarMutexGuard calls where appropriate.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/de1d75a0cd25f239cdc751dec75c9019fbcabd8e tdf#148453 Fix crash by turning off optimization for Objective-C selector It will be available in 7.6.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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/92d7325faac0ea005b373846cffbf87095abb525 tdf#148453 Fix crash by turning off optimization for Objective-C selector It will be available in 7.5.1. 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 is now in the nightly master build. Can anyone verify that this bug is fixed?
Verified fixed in Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 7f23dae00fedc9d7119b44b6c44d9eca4f8c87b8 CPU threads: 8; OS: Mac OS X 13.0.1; UI render: Skia/Metal; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-5-0": https://git.libreoffice.org/core/commit/7d09f9f54af7081991e37cb828e07cd759aa5d0d tdf#148453 Fix crash by turning off optimization for Objective-C selector It will be available in 7.5.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.