Bug 148435 - LibreOffice on macOS hangs on using window snapping / window manager (BetterTouchTool, Rectangle, Raycast, Amethyst, ...) or any other redraw, context switch, etc, from idle thread
Summary: LibreOffice on macOS hangs on using window snapping / window manager (BetterT...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.2.0.0.alpha0+
Hardware: ARM macOS (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:7.5.0 target:7.4.4
Keywords: bibisected, bisected, regression
: 140501 141722 142468 143119 145562 146124 146559 146721 146981 147085 147508 148030 148051 148069 148256 149024 149187 149807 150159 150566 150581 150596 151147 151363 151422 151513 151726 151730 152008 152171 152430 152489 152955 153169 154340 (view as bug list)
Depends on:
Blocks: macOS-UI-polish
  Show dependency treegraph
 
Reported: 2022-04-07 08:31 UTC by Peter Hagen
Modified: 2024-02-09 15:13 UTC (History)
44 users (show)

See Also:
Crash report or crash signature:


Attachments
Shown notification after killing libreoffice (33.98 KB, image/jpeg)
2022-04-07 08:31 UTC, Peter Hagen
Details
Spindump after libreoffice hanging (493.23 KB, application/zip)
2022-04-10 12:40 UTC, Peter Hagen
Details
Sample of stuck LibreOffice (127.82 KB, text/plain)
2022-12-13 14:49 UTC, Matten
Details
Sample of com.apple.hiservices-xpcservice, stuck while LO stuck (48.54 KB, text/plain)
2022-12-13 14:50 UTC, Matten
Details
Sample of stuck LibreOffice, stuck after being in background (128.90 KB, text/plain)
2022-12-14 09:40 UTC, Matten
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Hagen 2022-04-07 08:31:46 UTC
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.
Comment 1 steve 2022-04-07 09:01:44 UTC
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.
Comment 2 Peter Hagen 2022-04-07 11:16:58 UTC
Any suggestions on where to find, or how to get the logs? I don't get any crash report pop-up when this happens
Comment 3 steve 2022-04-08 11:36:50 UTC
https://apple.stackexchange.com/questions/26480/where-can-i-find-my-crash-logs

Open Console app via spotlight and select Reports > Crash Reports.
Comment 4 Peter Hagen 2022-04-08 11:52:46 UTC
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?
Comment 5 steve 2022-04-10 12:01:19 UTC
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
Comment 6 Peter Hagen 2022-04-10 12:40:41 UTC
Created attachment 179437 [details]
Spindump after libreoffice hanging
Comment 7 Peter Hagen 2022-04-10 12:41:25 UTC
Thanks for the info. I created the spindump after libreoffice was hanging. Hopefully you can find anything useful in it.
Comment 8 Telesto 2022-04-10 12:56:12 UTC
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?
Comment 9 Peter Hagen 2022-04-10 13:33:10 UTC
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.
Comment 10 Telesto 2022-04-11 07:55:19 UTC
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
Comment 11 Peter Hagen 2022-04-12 13:56:54 UTC
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
Comment 12 Telesto 2022-04-12 18:23:23 UTC
(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
Comment 13 Telesto 2022-04-12 18:24:26 UTC
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.
Comment 14 Telesto 2022-04-12 18:25:34 UTC
Adding CC: to Luboš Luňák
Comment 15 Telesto 2022-04-12 18:31:12 UTC
@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 :-)
Comment 16 Peter Hagen 2022-04-12 18:36:12 UTC
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.
Comment 17 steve 2022-05-12 09:44:15 UTC
*** Bug 149024 has been marked as a duplicate of this bug. ***
Comment 18 Peter Hagen 2022-07-22 21:18:54 UTC
Is there any progress with finding the issue?
Comment 19 steve 2022-07-25 10:46:17 UTC
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
Comment 20 Peter Hagen 2022-07-25 12:13:17 UTC
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.
Comment 21 Torsten Löhr 2022-07-26 13:32:28 UTC
I just reinstalled Collabora myself, but sadly it has the same issue for me.
Comment 22 Torsten Löhr 2022-07-26 13:32:47 UTC Comment hidden (obsolete)
Comment 23 Peter Hagen 2022-07-26 17:25:45 UTC
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.
Comment 24 steve 2022-08-02 08:44:25 UTC
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.
Comment 25 Torsten Löhr 2022-08-02 10:17:54 UTC
(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.
Comment 26 steve 2022-09-06 10:59:41 UTC
macOS 12.5.1
LibreOffice 7.4.0.3
persisting.
Comment 27 Francesc Rosés 2022-09-24 15:49:19 UTC
macOS Ventura 13.0 Beta (22A5352e)
macOS Monterey 12.6
LibreOffice 7.4.1.2

The problem persists. LibreOffice is unusable with macOS.
Comment 28 Peter Hagen 2022-09-25 08:54:05 UTC
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",
Comment 29 Alex Thurgood 2022-10-07 10:38:56 UTC
*** Bug 151363 has been marked as a duplicate of this bug. ***
Comment 30 Helmut Seidel M.A. 2022-10-11 12:39:53 UTC
(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.
Comment 31 Helmut Seidel M.A. 2022-10-14 08:16:13 UTC
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
Comment 32 Alex Thurgood 2022-11-02 15:48:16 UTC
*** Bug 151730 has been marked as a duplicate of this bug. ***
Comment 33 Alex Thurgood 2022-11-04 16:24:14 UTC
*** Bug 151894 has been marked as a duplicate of this bug. ***
Comment 34 Alex Thurgood 2022-11-04 16:32:05 UTC
*** Bug 151726 has been marked as a duplicate of this bug. ***
Comment 35 Alex Thurgood 2022-11-04 16:33:17 UTC
*** Bug 151422 has been marked as a duplicate of this bug. ***
Comment 36 Alex Thurgood 2022-11-04 16:34:08 UTC
*** Bug 150566 has been marked as a duplicate of this bug. ***
Comment 37 Alex Thurgood 2022-11-04 16:35:22 UTC
*** Bug 148256 has been marked as a duplicate of this bug. ***
Comment 38 Alex Thurgood 2022-11-15 13:43:06 UTC
*** Bug 147508 has been marked as a duplicate of this bug. ***
Comment 39 Alex Thurgood 2022-11-15 13:50:30 UTC
*** Bug 147085 has been marked as a duplicate of this bug. ***
Comment 40 Alex Thurgood 2022-11-15 13:54:25 UTC
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.
Comment 41 Alex Thurgood 2022-11-15 13:58:39 UTC
*** Bug 151147 has been marked as a duplicate of this bug. ***
Comment 42 Alex Thurgood 2022-11-15 14:08:42 UTC
*** Bug 146559 has been marked as a duplicate of this bug. ***
Comment 43 Noel Grandin 2022-11-17 17:31:28 UTC
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.
Comment 44 Michael Meeks 2022-11-21 17:35:55 UTC
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.
Comment 45 Michael Meeks 2022-11-21 17:51:00 UTC
Perhaps something like this:

https://gerrit.libreoffice.org/c/core/+/143046 tdf#148435 - avoid strange OS/X deadlock around AnyInput.

Warning - total un-tested ;-) ...
Comment 46 Alex Thurgood 2022-11-23 18:16:07 UTC
(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
Comment 47 Alex Thurgood 2022-11-23 18:16:42 UTC
*** Bug 152171 has been marked as a duplicate of this bug. ***
Comment 48 Aron Budea 2022-11-23 18:21:57 UTC
(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.
Comment 49 steve 2022-11-24 00:15:11 UTC
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
Comment 50 Commit Notification 2022-11-24 08:51:09 UTC
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.
Comment 51 steve 2022-11-24 14:15:32 UTC
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
Comment 52 Peter Hagen 2022-11-24 14:19:41 UTC
> @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
Comment 53 Alex Thurgood 2022-11-24 19:30:11 UTC
(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.
Comment 54 steve 2022-11-24 23:50:30 UTC
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.
Comment 55 Peter Hagen 2022-11-25 08:29:47 UTC
(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
Comment 56 Peter Hagen 2022-11-25 08:30:17 UTC Comment hidden (obsolete)
Comment 57 Commit Notification 2022-11-25 09:09:32 UTC
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.
Comment 58 Vincent Boudry 2022-11-25 13:08:48 UTC
(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 !
Comment 59 Paul 2022-11-29 09:02:45 UTC
(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.
Comment 60 Aron Budea 2022-11-29 09:25:43 UTC
(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/ ).
Comment 61 Paul 2022-11-29 09:41:17 UTC
(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.
Comment 62 Sierk Bornemann 2022-11-29 11:20:36 UTC
(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.
Comment 63 Paul 2022-11-29 11:50:26 UTC
(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.
Comment 64 Peter Hagen 2022-11-29 12:10:31 UTC
(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!
Comment 65 steve 2022-11-29 14:01:06 UTC
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.
Comment 66 Olaf Guse 2022-11-30 18:22:45 UTC
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.
Comment 67 Alex Thurgood 2022-11-30 20:12:48 UTC
(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.
Comment 68 Olaf Guse 2022-12-01 06:28:14 UTC
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
Comment 69 Buovjaga 2022-12-01 14:25:29 UTC
*** Bug 146721 has been marked as a duplicate of this bug. ***
Comment 70 steve 2022-12-12 23:37:32 UTC
*** Bug 152489 has been marked as a duplicate of this bug. ***
Comment 71 steve 2022-12-12 23:38:04 UTC
*** Bug 150159 has been marked as a duplicate of this bug. ***
Comment 72 Alex Thurgood 2022-12-13 09:56:30 UTC
*** Bug 152430 has been marked as a duplicate of this bug. ***
Comment 73 Alex Thurgood 2022-12-13 09:57:43 UTC
*** Bug 152008 has been marked as a duplicate of this bug. ***
Comment 74 Alex Thurgood 2022-12-13 09:59:12 UTC
*** Bug 150581 has been marked as a duplicate of this bug. ***
Comment 75 Matten 2022-12-13 14:49:54 UTC
Created attachment 184130 [details]
Sample of stuck LibreOffice
Comment 76 Matten 2022-12-13 14:50:58 UTC
Created attachment 184131 [details]
Sample of com.apple.hiservices-xpcservice, stuck while LO stuck
Comment 77 Matten 2022-12-13 14:56:09 UTC
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 :(
Comment 78 Alex Thurgood 2022-12-13 20:46:26 UTC
(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?
Comment 79 Matten 2022-12-14 09:40:15 UTC
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.
Comment 80 Alex Thurgood 2022-12-14 10:36:08 UTC
(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.
Comment 81 Alex Thurgood 2022-12-14 21:57:01 UTC
*** Bug 150596 has been marked as a duplicate of this bug. ***
Comment 82 Patrick Luby (volunteer) 2022-12-23 18:42:28 UTC
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.
Comment 83 Peter Hagen 2022-12-23 19:14:37 UTC
I’ll be more then happy to test it. So far the 7.5 build already work nicely for me
Comment 84 Patrick Luby (volunteer) 2022-12-23 20:08:35 UTC
(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.
Comment 85 Patrick Luby (volunteer) 2022-12-23 20:33:04 UTC
*** Bug 148051 has been marked as a duplicate of this bug. ***
Comment 86 Patrick Luby (volunteer) 2022-12-24 14:15:25 UTC
(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.
Comment 87 Alex Thurgood 2022-12-28 15:36:03 UTC
*** Bug 151513 has been marked as a duplicate of this bug. ***
Comment 88 Alex Thurgood 2022-12-30 10:05:11 UTC
*** Bug 142468 has been marked as a duplicate of this bug. ***
Comment 89 Alex Thurgood 2022-12-30 10:36:13 UTC
*** Bug 148030 has been marked as a duplicate of this bug. ***
Comment 90 Alex Thurgood 2023-01-12 16:15:36 UTC
*** Bug 146124 has been marked as a duplicate of this bug. ***
Comment 91 Telesto 2023-01-16 13:21:38 UTC
*** Bug 145562 has been marked as a duplicate of this bug. ***
Comment 92 Telesto 2023-01-16 18:55:05 UTC
*** Bug 152955 has been marked as a duplicate of this bug. ***
Comment 93 Telesto 2023-01-16 18:58:04 UTC
*** Bug 148069 has been marked as a duplicate of this bug. ***
Comment 94 Telesto 2023-01-16 19:06:24 UTC
*** Bug 143119 has been marked as a duplicate of this bug. ***
Comment 95 Matten 2023-01-23 10:29:18 UTC
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.
Comment 96 steve 2023-01-28 13:20:32 UTC
*** Bug 141722 has been marked as a duplicate of this bug. ***
Comment 97 Telesto 2023-01-28 14:20:38 UTC
*** Bug 153169 has been marked as a duplicate of this bug. ***
Comment 98 irrevdjohn 2023-02-02 15:23:08 UTC
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.
Comment 99 Thomas Studer 2023-02-02 17:01:54 UTC
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!
Comment 100 Telesto 2023-02-09 08:56:33 UTC
*** Bug 149807 has been marked as a duplicate of this bug. ***
Comment 101 Telesto 2023-03-24 06:24:57 UTC
*** Bug 154340 has been marked as a duplicate of this bug. ***
Comment 102 eisa01 2023-03-31 19:08:07 UTC
*** Bug 146981 has been marked as a duplicate of this bug. ***
Comment 103 Stéphane Guillou (stragu) 2023-07-28 09:07:44 UTC
*** Bug 140501 has been marked as a duplicate of this bug. ***
Comment 104 steve 2023-10-30 13:58:01 UTC
*** Bug 149187 has been marked as a duplicate of this bug. ***