I am having an annoying issue with LibreOffice (version 7.2.1.2, although it happened with 7.1 as well) on my MacBook Pro (Big Sur 11.4). When I select a snippet of text – it gets highlighted in blue, as in any text editor –, there is a significant probability that the mouse will turn into a swirling volleyball and LO become unresponsive, forcing me to kill the process. Please find the report of one of those crashes here:
The reasons why I think KM may be involved (and why I take the liberty to open a thread here) are the following :
I used to have one-line macros that selected menu items in LO (including items that would prompt the execution of Basic macros I had written). Using them caused it to crash. I have consequently discarded these macros, my LO macro groups have been disabled and as far as I can tell no attempt at firing a macro is underway when the program crashes (as stated, mere selecting of text seems to be enough). And yet, my current predicament looks suspiciously similar to what I went through before getting rid of the LO macros.
As long as LO remains unresponsive, the KM engine remains so too. Once I force quit LO, all the KM macros that I have tried to fire since the apparition of the volleyball (such as switching from one window or application to another) are executed at once, and the engine returns to its normal state.
Because I keep on saving my documents all the time, I seldom lose more than a sentence per crash, but it disrupts my workflow multiple times a day... Migrating to Microsoft Word is hardly an option : there are too many LO functionalities that I would desperately miss. If you were so kind as to offer your insights, I'd be very welcome!
Firstly, this is a LibreOffice crash, and you should report it to them, only they can fix it.
An easy test to see if Keyboard Maestro is involved, assuming it is repeatable is to quit Keyboard Maestro and Keyboard Maestro Engine and see if it is still repeatable.
Looking at the crash log, it appears that LibreOffice is “activating” a menu “Menu::Activate()” (whether this means selecting the menu or just looking at the menu for some reason I don't know). This is descending through some code to the point where it wants to get the accessibility data for the menu “OpenMenuForInspection”, “MenuData::HandleGetNamedAccessibleAttribute”, and later “Accessible::GetNamedAttributeData” and then “CopyAttributeValue”. But unfortunately at that point, for whatever reason, some sort of handler I guess, it is allowing the application main event to run (sort of), which leads to “Scheduler::CallbackTaskScheduling” and “Application::Execute” and now the app is doing other things which it is still trying to process the first things, and then it crashes.
That's quite complex, and resolving it may not be straight forward. I've dealt with bugs like this before and they are ugly because the app is in a state it never expects to be in.
Thank you very much for taking the time to answer even though, as you say, the issue doubtless pertains to LibreOffice. It would be clever to turn off KM to assess whether it is really involved or not in the crash, but I need it badly and can't afford to work without it for the many hours the test would take (no fawning intended). The event that triggers the crash – selecting a sentence, maybe copying it, I am not so sure – luckily does not always result in this unfortunate outcome. So no easy way occurs to me to quickly and conveniently reproduce the issue. Your analysis of the crash log is very interesting, I am so grateful for your help!
I've experienced a similar problem with both LibreOffice and KM not responding after Copy/Paste operations.
My solution (after reading multiple forum posts, and which seems to still be working) is to go to the Excluded Preferences Pane in KM, and to Exclude LibreOffice from the Clipboard History - third option down.