Description: LibreOffice (I use mostly Calc) freezes and becomes unresponsive when apparently doing nothing, or freeze happens upon clicking. I get the beachball cursor and must force quit. CPU usage is minimal (0.0%) All types of documents (large or small), sometimes just LO start screen. Have tried to restart in safe mode / erase user profile, to no avail. Never had the issue before version 7.2, where it suddenly happened. Even then, one can work for hours on a document without problems, followed by periods where it crashes repeatedly. Examples: - Clicking on a document in the start screen - Idle Calc window - Clicking in a Calc cell (link or not, anything) OpenGL is not enabled, and I deactivated the JAVA engine, to no avail. Steps to Reproduce: The bug is not very reproducible. It seems to occur more with an external screen, but it happens also with the internal one only. The only observable trend is that it seems to occur in series: there are very long periods without the problem, alternating with ones where it occurs every few minutes. Actual Results: Random freezes. Expected Results: Starting in safe mode / resetting user profile should clear the bug. Reproducible: Couldn't Reproduce User Profile Reset: Yes Additional Info: See attached process sampling info - maybe this can help.
Created attachment 178372 [details] Process sample in Activity Monitor for freeze in Start screen Launched LibreOffice => Start screen Tried to click on a file => freeze (Not 100% sure whether it was already frozen before, but it seems not: the beachball cursor was not active before I clicked on the file preview).
Created attachment 178373 [details] Process sample: freeze after opening file & moving to 2nd screen - Opened a small file in 1st window - Moved it to 2nd screen by dragging the window => Freeze
Created attachment 178374 [details] Process sample: Start screen, restart in safe mode dialog - Start in normal mode => Start screen - Help menu > Restart in Safe mode - Restart in Safe mode dialog displayed => Freeze after a few seconds
Created attachment 178375 [details] Process sample: freeze after opening empty file & moving its window in Safe mode - Created & saved new empty file "test.ods" (see next attachment) - Started LO in safe mode - Opened file using "Open" menu - Moved window around => Freeze
Comment on attachment 178372 [details] Process sample in Activity Monitor for freeze in Start screen - Start LO => Start screen (normal mode) - Try to click on a file => Freeze (beachball cursor, must force quit)
Created attachment 178377 [details] More complete system freeze report for LO Operations - Launched LO, opened two recent files => Freeze after moving one of the files to 2nd screen (no other action) (Attachment: more complete system report after force quit)
Created attachment 178379 [details] System freeze report: freeze upon reactivation (Laptop closed, only 2nd external screen) - Opened empty LO Calc file (see next attachment) - Moved window around & resized a few times => apparently OK - Activated Preview window on top of it & moved it around - Tried reactivating LO => freeze => Bug apparently not due to the actual file
Created attachment 178380 [details] Empty LO Calc file (for 178385 & 178379) The fresh empty Calc file that was used in previous freezes (in case there might be something corrupt in it)
Created attachment 180704 [details] Spindump for freeze with new user & creating new Writer document Again a new freeze. Here: 1) Safe mode - reunited user profile ; no special extensions 2) Created new empty writer document -> freeze (see also next attachment, screenshot) Notes: - Failure is hard to reproduce. The next time, it may work. - LO works fine for 2-3 months with excellent reliability, then has "failure periods" and freezes very often, even with the simplest of files or creating new empty files (as here), or even in the start screen (see further attachment). - CPU usage when frozen is always ca. 0.00%, it seems LO is "waiting for something", but what? - The program will also freeze with old files that were edited in a "good period", so I would not implicate the files.
Created attachment 180705 [details] Screenshot matched to previous attachment (spindump) Screenshot matched to previous spindump. Additional note: I tried to get rid of the freezes by switching from version 7.2.7 to 7.3.4, but behaviour was unchanged, same freezes (not better, not worse).
Created attachment 180709 [details] Spindump: freeze in start screen After failure and restarting the program, it will often fail in the start screen. If one is not very fast, it will hang in the safe mode start dialog (this example, next attachment = screenshot).
Created attachment 180710 [details] Screenshot: freeze in start screen Screenshot matched to previous spindump: freeze in start screen - confirmation of start in safe mode dialog.
Created attachment 180711 [details] LO user profile for last 4 attachments LO user profile for last 4 attachments (2 freezes). This profile was nominally reinitialised and should be essentially blank. Provided here to see if something could have been corrupted here already.
Created attachment 180712 [details] Spindump: freeze in safe mode, opening simple text file Steps taken here: - Started in safe mode > continue in safe mode - Double clicked on file in Finder --> freeze Next 2 attachments: screenshot + the file that was opened.
Created attachment 180713 [details] Screenshot: freeze in safe mode, opening simple text file The screenshot associated with the previous attachment
Created attachment 180714 [details] File: freeze in safe mode, opening simple text file The file on which LO froze upon opening it in safe mode. (Normally shouldn't be corrupt, as months since was last changed and used numerous times in between, without problems).
Possible solution / regression? =============================== After many frustrating attempts and searches on the internet, finding reports of problems with Java / JDK integration in LO, I dumped everything related to Java / JDK on my Mac, as I don't use it anymore. - In the user library: folder "Java" in Application Support - In the system library: all JDKs In System/Library: JavaVirtualMachines jdk1.8.0_91.jdk jdk1.8.0_102.jdk 1.6.0.jdk - In the LO user profile: java preferences Now, I've been working for some time without freezes, whereas LO was constantly crashing before. Maybe something with JDK integration could be the cause, possibly confusion between the different versions on the computer (required by different programs). Additional notes / unsolved issues 1) This doesn't explain why LO alternated between several trouble-free months and periods with repeated freezes. 2) I've obviously tried deactivating JDK usage in LO preferences, but this somehow didn't keep it from crashing. So I'd suggest looking in the Spindumps for anything in this direction. I couldn't find anything, except notice conspicuous waiting calls (mutexwait, etc.), which agrees with LO becoming unresponsive with essentially zero CPU usage. So it seems to wait for something that never comes: deadlock / race condition / bug in JDK? Does that sound realistic?
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Thomas Maeder from comment #17) > In System/Library: JavaVirtualMachines > jdk1.8.0_91.jdk > jdk1.8.0_102.jdk > 1.6.0.jdk None of the above versions should really be used with LO anymore on macOS, in fact, some of them are pretty much guaranteed to cause crashes at some stage. I believe that currently accepted versions on macOS are JDK >= 17. For example, I have: /Library/Java/JaveVirtualMachines/jdk-17_aarch64.jdk/Contents/Home as my recognized path to the JDK when using the macOS ARM-build of LO. > So I'd suggest looking in the Spindumps for anything in this direction. I > couldn't find anything, except notice conspicuous waiting calls (mutexwait, > etc.), which agrees with LO becoming unresponsive with essentially zero CPU > usage. So it seems to wait for something that never comes: deadlock / race > condition / bug in JDK? Does that sound realistic? Yes, it could well be an synchronization issue that causes a deadlock - whether that is due to the JDK or not is up for debate, but that kind of deadlock has also happened in the past when instantiating some functional pathway (e.g. formerly automatic spellchecking, or some other Java call).
(In reply to Alex Thurgood from comment #19) > (In reply to Thomas Maeder from comment #17) > > > > In System/Library: JavaVirtualMachines > > jdk1.8.0_91.jdk > > jdk1.8.0_102.jdk > > 1.6.0.jdk > > None of the above versions should really be used with LO anymore on macOS, > in fact, some of them are pretty much guaranteed to cause crashes at some > stage. > Thank you for the information! So I guess this essentially solves the issue. Maybe one should implement a kind of JDK version checking (or at least warn of potential incompatibility, such as "use at your risk and peril"), because the resulting program freezes are annoying and very hard to trace. What do you think?
Probably just another way to trigger bug 148435, a deadlock situation for which an alleged offending commit has been identified, but so far no fix proposed.
Always this in the spindump: 2713 Idle::Start() (in libvcllo.dylib) + 14 [0x10f30e4fe] 2713 Task::Start() (in libvcllo.dylib) + 35 [0x10f347213] 2713 std::__1::mutex::lock() (in libc++.1.dylib) + 9 [0x7fff64f39c7f] 2713 _pthread_mutex_lock_slow (in libsystem_pthread.dylib) + 253 [0x7fff672cb4c8] 2713 _pthread_mutex_lock_wait (in libsystem_pthread.dylib) + 83 [0x7fff672cdb9d] 2713 __psynch_mutexwait (in libsystem_kernel.dylib) + 10 [0x7fff67105a46] or this in the full Apple stack trace: 11 std::__1::mutex::lock() + 9 (libc++.1.dylib + 236671) [0x7fff64f39c7f] 11 _pthread_mutex_lock_slow + 253 (libsystem_pthread.dylib + 5320) [0x7fff672cb4c8] 11 __psynch_mutexwait + 10 (libsystem_kernel.dylib + 117318) [0x7fff67105a46] *11 psynch_mtxcontinue + 0 (pthread + 31325) [0xffffff7f82ad7a5d] (blocked by pthread mutex owned by this thread) Marking as DUP of bug 148435 *** This bug has been marked as a duplicate of bug 148435 ***