Created attachment 179368 [details] Shown notification after killing libreoffice I have a strange issue with Libreoffice crashing when using Magnet or Rectangle window snapping. What happens that in some cases (not always), LibreOffice hangs and gives me the color waiting wheel. I can then force quit LibreOffice, and in case of using Magnet, I get a "Can't Be More Narrow" notification. On using BetterTouchTool, it seems to crashes less. When not using a window snapping tool, it seems to crash allot less. But yeah... I do require window snapping... Does anyone have similar experiences, and maybe a solution? Till now I haven't found any indication that others, accept my co-worker, having these issues Running latest Monterey (12.3 (21E230)), but this issue has been for every Monterey version, not sure about older macOs versions. Having installed LibreOffice 7.3.2.2, but is has been happening with other versions also.
Please attach the crash log you receive after force quitting LO. I confirm those issues also when using Raycast as window manager as well as Rectangle.
Any suggestions on where to find, or how to get the logs? I don't get any crash report pop-up when this happens
https://apple.stackexchange.com/questions/26480/where-can-i-find-my-crash-logs Open Console app via spotlight and select Reports > Crash Reports.
Unfortunately not. Even when I wait till it says that LibreOffice is unresponsive, and then force quit the application, no reports are shown anywhere. Not in Application Support, and not in Console.app. I'm actually assuming LibreOffice doesn't really crash, but hangs stuck somewhere. On calling a kill {PID}, it kill's the application without any issue, instead of having to use -KILL or something like that. On "recording" events in console.app, I also don't see any error message related to LibreOffice hanging, or Rectangle for that matter. Any suggestions?
While LO is hanging you could create spin dump and process sample. There are various documentations on this on the web. Here is one: https://avid.secure.force.com/pkb/articles/en_US/How_To/Sample-Process-Spindump-macOS?retURL=%2Fpkb%2Fapex%2FKB_Render_HowTo
Created attachment 179437 [details] Spindump after libreoffice hanging
Thanks for the info. I created the spindump after libreoffice was hanging. Hopefully you can find anything useful in it.
Well not that good in reading backtraces, but looks like mutex gets locked, and waiting for some response .. and gets stuck there. 1000 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 28 (CoreFoundation + 495068) [0x1a4fc2ddc] 1000 -[SalFrameWindow windowDidResize:] + 196 (libvclplug_osxlo.dylib + 322340) [0x10838eb24] 1000 ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) + 2716 (libvcllo.dylib + 970852) [0x106a65064] 1000 ImplHandleResize(vcl::Window*, long, long) + 560 (libvcllo.dylib + 966840) [0x106a640b8] 1000 Idle::Start(bool) + 28 (libvcllo.dylib + 3598004) [0x106ce66b4] 1000 Task::Start(bool) + 44 (libvcllo.dylib + 3820992) [0x106d1cdc0] 1000 std::__1::mutex::lock() + 16 (libc++.1.dylib + 61780) [0x1a4e53154] 1000 _pthread_mutex_firstfit_lock_slow + 248 (libsystem_pthread.dylib + 7416) [0x1a4efccf8] 1000 __psynch_mutexwait + 8 (libsystem_kernel.dylib + 18264) [0x1a4ec7758] *1000 psynch_mtxcontinue + 0 (pthread + 9964) [0xfffffe000a54a93c] (blocked by turnstile waiting for this thread) Is this also happening with older versions? Lets say - a bit randomly - LibreOffice 6.3?
It seems that all up to 7.1.8.1 (x64) work fine. All newer ones I tried have this problem. I tried aarch64 and x64.
Most ideal would be a bibisect.. which takes some time to do https://wiki.documentfoundation.org/QA/Bibisect/macOS More or less a summary: 1) In a terminal: git clone https://bibisect.libreoffice.org/mac64-7.2.git (assuming it started with 7.2) 2. Type: git checkout latest 2. Launch LibreOffice.app in from the mac64-7.2 folder in the user folder with open LibreOffice.app/ 4. Git checkout oldest (check if the issue not present) 5. If 3 & 4 are the case: 6. Enter: git bisect start latest oldest (and hit enter) 7. open LibreOffice.app/ 8. git bisect good # if the bug is not there | git bisect bad # if the bug is there 9. Repeat 7/8 until all steps are done.. now a commit should be identified In the other case I have to try to reproduce and if so, bibisect.. but could take some time before I do
I tried it, and it seems that this hash is the last that doesn't hang: > source f343ad6d8a78798814c9d38261043619b4e2b487 I have to state that sometimes it took just a few seconds and other times it took a long time. But > source d3b498cc4732f964919fecb265085cefcc422469``` did hang within 2 seconds. So hopefully you can find something useful from this
(In reply to Peter Hagen from comment #11) > I tried it, and it seems that this hash is the last that doesn't hang: > > > source f343ad6d8a78798814c9d38261043619b4e2b487 -> Well this commit surely isn't it.. based on the commit message https://cgit.freedesktop.org/libreoffice/core/commit/?id=f343ad6d8a78798814c9d38261043619b4e2b487 > > I have to state that sometimes it took just a few seconds and other times it > took a long time. But > > > source d3b498cc4732f964919fecb265085cefcc422469``` > > did hang within 2 seconds. So hopefully you can find something useful from > this This one looks more promising: https://cgit.freedesktop.org/libreoffice/core/commit/?id=d3b498cc4732f964919fecb265085cefcc422469
Bisected to: author Luboš Luňák <l.lunak@collabora.com> 2021-02-07 16:34:38 +0100 committer Luboš Luňák <l.lunak@collabora.com> 2021-02-07 18:57:30 +0100 commit d3b498cc4732f964919fecb265085cefcc422469 (patch) tree b5cc5bbc381e18a2cad621b75cbe7401db0c585c parent f343ad6d8a78798814c9d38261043619b4e2b487 (diff) invoke idle priority timers only when actually idle The 'Idle' timers are misnamed. They are zero-timeout times, i.e. they are invoked immediately after returning to the main loop. But that does not necessarily mean they are invoked when idle, there may be e.g. user input pending in the system event queue. In fact, LO events are processed before system events, which means that 'Idle' timers are normally processed before user input. Besides being confused, this also leads to poor performance in some cases, such as when using mouse wheel to zoom in a large document. This results in several mouse wheel events, each of which will result in adjusting the zoom and that causing a repaint. Repaints are internally handled using a TaskPriority::REPAINT 'Idle', and so what happens is zoom->repaint->zoom->repaint->zoom->repaint instead of the more efficient zoom->zoom->zoom->repaint. This change (besides trying to clarify the confusion in the docs) delays invoking tasks with priorities TaskPriority::HIGH_IDLE and lower if there is user input or repaint events in the OS queue. That means that tasks using idle priorities actually will be invoked only when idle (barring background threads etc.). I'm reasonably certain this is a safe change, there's no guarantee when exactly tasks will be invoked (e.g. other tasks with a higher priority go first) and explicitly specifying such a priority means asking for it. I already implemented this once in 06d731428ef6cf93c7333e8228b, and it was also again done in 87199d3829257420429057336283, but apparently these have been removed. There was d348035a60361a1b9ba9e 'Drop special idle handling' with the reasoning that 'Idles are just instant timers'. Which strictly technically speaking is true due to 'Idle' being a misnomer, but the point is that some idles should be actual idles and that's why they need to be handled specially.
Adding CC: to Luboš Luňák
@Peter Hagen Thanks for the bibisect! Most people don't get that far. OTOH, I kind of guessed you would do the bibisect, based on your occupation :-)
My pleasure. This bug is annoying me enough to hunt it down haha. And unfortunately I don't have any experience in LibreOffice development, else I would attempt to help find it.
*** Bug 149024 has been marked as a duplicate of this bug. ***
Is there any progress with finding the issue?
Sadly no :( You could try NeoOffice which does not have this issue since it is based on a very old LibreOffice version: https://github.com/neooffice/NeoOffice/releases
Yeah, really old. That's not really what I want to do. I just bought Collabora Office from the App Store to test it. It seems this issue is not in it.
I just reinstalled Collabora myself, but sadly it has the same issue for me.
Yeah, I cheered too early. Before I didn't get it to crash, but yesterday I tried again and it hanged like LibreOffice. I also send a message to Collabora about this.
Raising priorite to High | Major since window managers are common and a hang is preventing work from being done. One could even argue data loss for cases recovery won't bring back latest document state.
(In reply to steve from comment #24) Thanks a lot for increasing the level on this one. It really makes it very challenging for my work. To any person working on this problem: If you need cooperation while searching for this issue please feel free to contact me. If I can help, I will.
macOS 12.5.1 LibreOffice 7.4.0.3 persisting.
macOS Ventura 13.0 Beta (22A5352e) macOS Monterey 12.6 LibreOffice 7.4.1.2 The problem persists. LibreOffice is unusable with macOS.
I don't know if anyone is trying to get it solved, but I would like to help get this resolved. I'm not a C++ + LibreOffice developer, so my help might be limited. We already identified at what commit this effect started to occur. This change below seems to be the reason it occurs: ``` diff --git a/vcl/source/app/scheduler.cxx b/vcl/source/app/scheduler.cxx index b325f9238a7d..57b8176521f7 100644 --- a/vcl/source/app/scheduler.cxx +++ b/vcl/source/app/scheduler.cxx @@ -430,6 +430,17 @@ bool Scheduler::ProcessTaskScheduling() << " of " << nTasks << " tasks" ); UpdateSystemTimer( rSchedCtx, nMinPeriod, true, nTime ); + // Delay invoking tasks with idle priorities as long as there are user input or repaint events + // in the OS event queue. This will often effectively compress such events and repaint only + // once at the end, improving performance in cases such as repeated zooming with a complex document. + if ( pMostUrgent && pMostUrgent->mePriority >= TaskPriority::HIGH_IDLE + && Application::AnyInput( VclInputFlags::MOUSE | VclInputFlags::KEYBOARD | VclInputFlags::PAINT )) + { + SAL_INFO( "vcl.schedule", tools::Time::GetSystemTicks() + << " idle priority task " << pMostUrgent << " delayed, system events pending" ); + pMostUrgent = nullptr; + } ``` If I check out the latest code, there are some changes in this part: ``` // Delay invoking tasks with idle priorities as long as there are user input or repaint events // in the OS event queue. This will often effectively compress such events and repaint only // once at the end, improving performance in cases such as repeated zooming with a complex document. if ( pMostUrgent && pMostUrgent->mePriority >= TaskPriority::HIGH_IDLE && Application::AnyInput( VclInputFlags::MOUSE | VclInputFlags::KEYBOARD | VclInputFlags::PAINT )) { SAL_INFO( "vcl.schedule", tools::Time::GetSystemTicks() << " idle priority task " << pMostUrgent << " delayed, system events pending" ); pMostUrgent = nullptr; nMinPeriod = 0; } if (InfiniteTimeoutMs != nMinPeriod) SAL_INFO("vcl.schedule", "Calculated minimum timeout as " << nMinPeriod << " of " << nTasks << " tasks"); UpdateSystemTimer(rSchedCtx, nMinPeriod, true, nTime); if ( !pMostUrgent ) return; ``` Further in the code, there is an unlock call. Could it be that exiting this code, could result in calling the unlock? I have no idea what this code does, just trying to think "out loud",
*** Bug 151363 has been marked as a duplicate of this bug. ***
(In reply to Francesc Rosés from comment #27) > macOS Ventura 13.0 Beta (22A5352e) > macOS Monterey 12.6 > LibreOffice 7.4.1.2 > > The problem persists. LibreOffice is unusable with macOS. I agree, as I developed several Base- and basic-applications which need several LO-Apps opened simultaniously - currently it takes just seconds unti LO hangs. Today I therefores witched to OpenOffice 4.1.13 which seems a more conservative, but works fine so far.
Please excuse my typos in the last post. Well, I've been a bit over optimistic. Especially while creating database forms in design mode or testing basic code, openoffice tends to sudden crashes, which at times can only be cured by uninstalling OOo completely and reinstalling it. So I moved back to LibreOffice... and hope for a cure
*** Bug 151730 has been marked as a duplicate of this bug. ***
*** Bug 151894 has been marked as a duplicate of this bug. ***
*** Bug 151726 has been marked as a duplicate of this bug. ***
*** Bug 151422 has been marked as a duplicate of this bug. ***
*** Bug 150566 has been marked as a duplicate of this bug. ***
*** Bug 148256 has been marked as a duplicate of this bug. ***
*** Bug 147508 has been marked as a duplicate of this bug. ***
*** Bug 147085 has been marked as a duplicate of this bug. ***
I upped the priority on this, given the number of duplicates, the bibisected commit, and the fact that LO is virtually unusable in a real world scenario on macOS without this being sorted. If that doesn't meet the requirements for being critical, well, so be it.
*** Bug 151147 has been marked as a duplicate of this bug. ***
*** Bug 146559 has been marked as a duplicate of this bug. ***
So we have a non-recursive mutex here: ImplSchedulerContext at https://opengrok.libreoffice.org/xref/core/vcl/inc/svdata.hxx?r=eaa0954f#373 And we have Scheduler::CallbackTaskScheduling https://opengrok.libreoffice.org/xref/core/vcl/source/app/scheduler.cxx?r=91ba9654&mo=11629&fi=330#426 which takes the mutex, and then calls AquaSalInstance::AnyInput(VclInputFlags) https://opengrok.libreoffice.org/xref/core/vcl/osx/salinst.cxx?r=467085bf#676 which calls [NSApp nextEventMatchingMask: which ends up calling [SalFrameWindow windowDidResize:] ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) ImplHandleResize(vcl::Window*, long, long) and then finally Idle::Start(bool) which tries to take the scheduler mutex again, and deadlocks. Not sure what the right solution would be.
This is really grim: Calling: AquaSalInstance::AnyInput(VclInputFlags) Seems to lead to un-controlled re-enterancy that is completely un-related to input - to whit creating new windows, and re-sizing them - which triggers re-rendering: amazing Apple API ;-) I can't see any way to only look for input events in this API either. Anyhow - good to be aware of this I suppose: And we have Scheduler::CallbackTaskScheduling https://opengrok.libreoffice.org/xref/core/vcl/source/app/scheduler.cxx?r=91ba9654&mo=11629&fi=330#426 which takes the mutex, and then calls AquaSalInstance::AnyInput(VclInputFlags) https://opengrok.libreoffice.org/xref/core/vcl/osx/salinst.cxx?r=467085bf#676 which calls I expect the 'easiest' fix is to move the check for AnyInput down the function some way so this: 422 // Delay invoking tasks with idle priorities as long as there are user input or repaint events 423 // in the OS event queue. This will often effectively compress such events and repaint only 424 // once at the end, improving performance in cases such as repeated zooming with a complex document. 425 if ( pMostUrgent && pMostUrgent->mePriority >= TaskPriority::HIGH_IDLE 426 && Application::AnyInput( VclInputFlags::MOUSE | VclInputFlags::KEYBOARD | VclInputFlags::PAINT )) 427 { 428 SAL_INFO( "vcl.schedule", tools::Time::GetSystemTicks() 429 << " idle priority task " << pMostUrgent << " delayed, system events pending" ); 430 pMostUrgent = nullptr; 431 nMinPeriod = 0; 432 } Happens after the 'Unlock()' - of course - if we find that now is not a good time to process this event after the unlock - then we should not pTask->Invoke() and then re-add the pTask to the scheduler, mend the scheduler stack etc. again. at the end. Possibly to do that we need to clobber bTaskAlive in this case - but quite possibly nothing much more needs doing.
Perhaps something like this: https://gerrit.libreoffice.org/c/core/+/143046 tdf#148435 - avoid strange OS/X deadlock around AnyInput. Warning - total un-tested ;-) ...
(In reply to Michael Meeks from comment #45) > Perhaps something like this: > > https://gerrit.libreoffice.org/c/core/+/143046 tdf#148435 - avoid strange > OS/X deadlock around AnyInput. > > Warning - total un-tested ;-) ... Hi Michael, Has this commit made it into latest master ? If so, I could give it a spin... Alex
*** Bug 152171 has been marked as a duplicate of this bug. ***
(In reply to Alex Thurgood from comment #46) > Has this commit made it into latest master ? If so, I could give it a spin... To quote his note in the gerrit patch: > WIP patch - badly needs testing by someone on Mac to see if it helps - and I guess on Linux/Windows too vs. the original bug Lubos was fixing.
Are there builds available to test? For all I know todays main build still crashes. Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1435c5b12646269e2b5b58ec7d51626dce6505db CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: de-DE (en_DE.UTF-8); UI: en-US Calc: threaded
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8b442d7fae17660b3665da2c1f7a084341987693 tdf#148435 - avoid strange OS/X deadlock around AnyInput. 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.
This bug has prevented any work in LibreOffice for the past months. It affected stable, fresh and main builds basically forcing macOS users to downgrade to older versions with potential unfixed security issues. Couldn't be happier to report I am no longer able to reproduce this crash with Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8467aa93e2038b3030e1add94e0ca6cc4ad44032 CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx Locale: de-DE (en_DE.UTF-8); UI: en-US Calc: threaded Thanks so much Michael and Noel for looking into this and as it seems fixing the problem. @Noel should we set this to fixed verified? Can others verify todays main build no longer exposes the problematic behavior? https://dev-builds.libreoffice.org/daily/master/current.html
> @Noel should we set this to fixed verified? Can others verify todays main > build no longer exposes the problematic behavior? > https://dev-builds.libreoffice.org/daily/master/current.html I'm waiting for the M1 version to appear, to test it
(In reply to Peter Hagen from comment #52) > > @Noel should we set this to fixed verified? Can others verify todays main > > build no longer exposes the problematic behavior? > > https://dev-builds.libreoffice.org/daily/master/current.html > > I'm waiting for the M1 version to appear, to test it Unfortunately, there aren't any that I'm aware of, only x86_64 dev builds.
Taking the liberty to close this as fixed verified. I would be surprised if this persisted specifically on Apple Silicon. But who knows. In that case please file a follow-up bug and interlink the two issues.
(In reply to Alex Thurgood from comment #53) > Unfortunately, there aren't any that I'm aware of, only x86_64 dev builds. There is a aarch build visible, from today, but the disk image seems to be damaged. So, I'll wait for the official release
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/e63fbf524bf4bb1a247b55a31745a6ced1661532 tdf#148435 - avoid strange OS/X deadlock around AnyInput. It will be available in 7.4.4. 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 steve from comment #51) > This bug has prevented any work in LibreOffice for the past months. It > affected stable, fresh and main builds basically forcing macOS users to > downgrade to older versions with potential unfixed security issues. > > Couldn't be happier to report I am no longer able to reproduce this crash > with > > Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 8467aa93e2038b3030e1add94e0ca6cc4ad44032 > CPU threads: 8; OS: Mac OS X 13.0.1; UI render: default; VCL: osx > Locale: de-DE (en_DE.UTF-8); UI: en-US > Calc: threaded > > Thanks so much Michael and Noel for looking into this and as it seems fixing > the problem. > > @Noel should we set this to fixed verified? Can others verify todays main > build no longer exposes the problematic behavior? > https://dev-builds.libreoffice.org/daily/master/current.html Tested the Impress module with: Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8467aa93e2038b3030e1add94e0ca6cc4ad44032 CPU threads: 4; 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 So far, no crash and a more responsive application in window resizing and object grabbing. What a relief !
(In reply to Peter Hagen from comment #55) > > There is a aarch build visible, from today, but the disk image seems to be > damaged. So, I'll wait for the official release I too am keen to test this but as of today (29 Nov 2022) the aarch build is still damaged and I can't install it.
(In reply to Paul from comment #59) > I too am keen to test this but as of today (29 Nov 2022) the aarch build is > still damaged and I can't install it. Is it this one? https://dev-builds.libreoffice.org/daily/master/MacOSX-aarch64@tb93-TDF/ Can you share the error you're getting? It may be worth bringing that up on the infra IRC channel (#tdf-infra on libera.chat), or on redmine ( https://redmine.documentfoundation.org/ ).
(In reply to Aron Budea from comment #60) > (In reply to Paul from comment #59) > > I too am keen to test this but as of today (29 Nov 2022) the aarch build is > > still damaged and I can't install it. > Is it this one? > https://dev-builds.libreoffice.org/daily/master/MacOSX-aarch64@tb93-TDF/ > Can you share the error you're getting? It may be worth bringing that up on > the infra IRC channel (#tdf-infra on libera.chat), or on redmine ( > https://redmine.documentfoundation.org/ ). Yes, that's the one. I have just followed your link and tried installing again. Same error. The error message is: "LibreOfficeDev.app" is damaged and can't be opened. You should move it to the Bin. There was an earlier-dated build yesterday with the same error. I had hoped that this morning's 29th Nov build might have fixed it. I have also mentioned it on the Ask LibreOffice site. I'm not familiar with the other places you mention and am probably not technical enough to be helpful. I'll keep monitoring and am happy to help out if I can.
(In reply to Paul from comment #61) > (In reply to Aron Budea from comment #60) > > (In reply to Paul from comment #59) > > > I too am keen to test this but as of today (29 Nov 2022) the aarch build is > > > still damaged and I can't install it. > > Is it this one? > > https://dev-builds.libreoffice.org/daily/master/MacOSX-aarch64@tb93-TDF/ > > Can you share the error you're getting? It may be worth bringing that up on > > the infra IRC channel (#tdf-infra on libera.chat), or on redmine ( > > https://redmine.documentfoundation.org/ ). > > > Yes, that's the one. I have just followed your link and tried installing > again. Same error. > > > The error message is: > "LibreOfficeDev.app" is damaged and can't be opened. > You should move it to the Bin. > > > > There was an earlier-dated build yesterday with the same error. I had hoped > that this morning's 29th Nov build might have fixed it. I can confirm the issue, I've noticed it, too. Try to remove the quarantine bit of the App, which is added by the system after downloading it with xattr -dr com.apple.quarantine LibreOfficeDev.app and try again. After removing it, the App should open as expected. I have no idea, why this suddenly is broken.
(In reply to Sierk Bornemann from comment #62) > Try to remove the quarantine bit of the App, which is added by the system > after downloading it with > > xattr -dr com.apple.quarantine LibreOfficeDev.app > > and try again. After removing it, the App should open as expected. > I have no idea, why this suddenly is broken. Thank you. That worked and I was then able to run the aarch version of the LO Dev app. I have now done some checking and I'm very glad to say the hanging on window-switching (using Cmd+Tilde) seems to be fixed. Wonderful.
(In reply to Sierk Bornemann from comment #62) > > xattr -dr com.apple.quarantine LibreOfficeDev.app > This works for me. And indeed, I can move the window insanely again with snapping (by using Rectangle and hotkeys) without issues so far!
The warning for the main builds from https://dev-builds.libreoffice.org/daily/master/current.html is expected, since those are unsigned. Right-click > open to work around that. You may have to do this twice.
Installed MacOSX-x86_64@tb92-TDF to verify bug 151894 - FILEOPEN a Base Document with customized event for open a start form by "open document" LO stuck (was listed as duplicate of 148435)- problem still exist. Spinning ball and I have to interrupt process. Only able to start with disable macro.
(In reply to Olaf Guse from comment #66) > Installed MacOSX-x86_64@tb92-TDF to verify bug 151894 - FILEOPEN a Base > Document with customized event for open a start form by "open document" LO > stuck (was listed as duplicate of 148435)- problem still exist. Spinning > ball and I have to interrupt process. Only able to start with disable macro. @Olaf : is the trace when it hangs the same, or different to the one I identified in bug 151894? If the trace on hang is not the same as the one in bug 151894, it might be a manifestation of bug 95191 or bug 98491. What I'm trying to say is that even if this bug report appears to be fixed, the continued problem you are experiencing needs to be investigated again. I'll reopen bug 151894 and set as unconfirmed pending further investigation.
I (In reply to Alex Thurgood from comment #67) > @Olaf : is the trace when it hangs the same, or different to the one I > identified in bug 151894? > > If the trace on hang is not the same as the one in bug 151894, it might be a > manifestation of bug 95191 or bug 98491. > > What I'm trying to say is that even if this bug report appears to be fixed, > the continued problem you are experiencing needs to be investigated again. > I'll reopen bug 151894 and set as unconfirmed pending further investigation. @Alex: For me there is no change in behavior with the new build. Maybe reopen 151894 and verify the bug 151894 with the new build by a other user would help
*** Bug 146721 has been marked as a duplicate of this bug. ***
*** Bug 152489 has been marked as a duplicate of this bug. ***
*** Bug 150159 has been marked as a duplicate of this bug. ***
*** Bug 152430 has been marked as a duplicate of this bug. ***
*** Bug 152008 has been marked as a duplicate of this bug. ***
*** Bug 150581 has been marked as a duplicate of this bug. ***
Created attachment 184130 [details] Sample of stuck LibreOffice
Created attachment 184131 [details] Sample of com.apple.hiservices-xpcservice, stuck while LO stuck
Hi, I'm coming here since my original report (https://bugs.documentfoundation.org/show_bug.cgi?id=151730) has been closed as a duplicate of this bug. I'm not sure it really is, but here we are... New observations: 1) I could not reproduce the issue while my external screen was not attached (and too far away for testing). I now have the external screen again, and again LO gets stuck. 2) I noticed that at the same time as LO was stuck I had another stuck process,'com.apple.hiservices-xpcservice'. LO appears to used it... 3) I took samples of the two processes and attached them. 4) From Thursday on I will be again without external monitor :(
(In reply to Matten from comment #77) > Hi, > > I'm coming here since my original report > (https://bugs.documentfoundation.org/show_bug.cgi?id=151730) has been closed > as a duplicate of this bug. I'm not sure it really is, but here we are... > @Matten : have you tried the 7.5 pre-release, and if so, is the problem still reproducible with that version?
Created attachment 184139 [details] Sample of stuck LibreOffice, stuck after being in background Today LO was stuck again, this time com.apple.hiservices-xpcservice was not stuck.
(In reply to Matten from comment #79) > Created attachment 184139 [details] > Sample of stuck LibreOffice, stuck after being in background > > Today LO was stuck again, this time com.apple.hiservices-xpcservice was not > stuck. @Matten : please test with 7.5, the fix that was provided won't be backported to 7.3.x branch, which is already end of life.
*** Bug 150596 has been marked as a duplicate of this bug. ***
I think I may have finally figured out what is causing this bug and I have posted the following patch: https://gerrit.libreoffice.org/c/core/+/144786 In theory, the above patch should not only fix this bug, but also the various other macOS hanging bugs that have the following two lines at the bottom of the first thread's stack like in attachment 184139 [details]: Task::Start(bool) std::mutex::lock() The patch needs still needs to be reviewed and tested before it appears in a nightly build. But if there any people who have a macOS LibreOffice build that can test the patch, that would be very much appreciated.
I’ll be more then happy to test it. So far the 7.5 build already work nicely for me
(In reply to Peter Hagen from comment #83) > I’ll be more then happy to test it. So far the 7.5 build already work nicely > for me If it helps, I noticed that in your sample in attachment 179437 [details], LibreOffice was hanging during an accessibility event that sets the position and/or size of one of LibreOffice's windows. I assume that that type of accessibility are coming from whatever window snapping application you have installed. @Matten's samples are occurring to "screens changed" events. Those occur when plugging in or unplugging an external monitor or changing display settings in the System Preferences application.
*** Bug 148051 has been marked as a duplicate of this bug. ***
(In reply to Patrick Luby from comment #82) > I think I may have finally figured out what is causing this bug and I have > posted the following patch: > > https://gerrit.libreoffice.org/c/core/+/144786 > Update: My patch is not needed. I now see that in comment 50 already fixed this bug. I don't know how I missed that patch, but it is clear that my patch is duplicative and does not add any improvement to @Noel Grandin's patch. Sorry for any confusion.
*** Bug 151513 has been marked as a duplicate of this bug. ***
*** Bug 142468 has been marked as a duplicate of this bug. ***
*** Bug 148030 has been marked as a duplicate of this bug. ***
*** Bug 146124 has been marked as a duplicate of this bug. ***
*** Bug 145562 has been marked as a duplicate of this bug. ***
*** Bug 152955 has been marked as a duplicate of this bug. ***
*** Bug 148069 has been marked as a duplicate of this bug. ***
*** Bug 143119 has been marked as a duplicate of this bug. ***
Hi, I finally had some time to test 7.5, and I can report that it indeed fixes the issue I had reported. Thanks a lot.
*** Bug 141722 has been marked as a duplicate of this bug. ***
*** Bug 153169 has been marked as a duplicate of this bug. ***
Happy to confirm that my bug (reported as duplicate 152489) appears to be fixed in LO 7.5.0.3 My thanks to all the clever people who put this right! Skimming the dialogue between those who worked on it shows just how elusive these critters can be to track down and remediate. I didn’t understand the half of it. Tip of the hat to you all.
Thanks to everybody who helped to fix this minor but annoying bug and of course everybody who helped and helps to create this great Open Source Program!
*** Bug 149807 has been marked as a duplicate of this bug. ***
*** Bug 154340 has been marked as a duplicate of this bug. ***
*** Bug 146981 has been marked as a duplicate of this bug. ***
*** Bug 140501 has been marked as a duplicate of this bug. ***
*** Bug 149187 has been marked as a duplicate of this bug. ***