I’ve now been told by 2 editors that disconnecting external displays totally fixes the issue. And the beach balling returns the second they reconnect.
This is with LG 5K and Studio display. Issue even happens when no other peripherals are connected. So feels like some kind of display/GPU issue. (Still waiting for editors to send me spin dumps)...
I just connected my Studio display and LG 5K to my M1 Ultra Mac Studio. Both are directly connected via separate Thunderbolt 3 cables to the Mac Studio. In FCP I put the viewer on the extended LG 5K. So far I don't see the problem, but I've only done simple FCP tasks. Is there anything else in common about certain FCP effects, plugins, editing tasks, etc? If I could reproduce it I could make my own spindump.
There is no common task apart from playing back a timeline, or clips in the browser. 1080p ProRes Proxy, no effects etc...
Thomas, I spent a long time today studying those spindumps, but they are harder to analyze than a crash dump. They are more difficult because the process is not crashed but deranged and the many threads are in various states. Each of the 3 spindumps were a bit different but I can make a few observations:
When I do an FCP spindump on my M1 Ultra with Studio and LG 5k monitors connected, I don't see CVDisplayLink; not sure if it has any meaning. In FCP if you change Window>Show In Secondary Display to a different configuration, does the problem still happen?
If you are using the new Universal Control feature, try turning that off in System Preferences>Displays>Universal Control.
On the problematic two-monitor machines, are all the Thunderbolt monitors directly connected to the M1 Max or M1 Ultra machines, or via a hub of some kind? As a test can you try to connect each monitor directly? I realize on a MacBook Pro you may not have sufficient ports for that, but if you have any Mac Studio machines maybe you could try that.
Numerous threads are waiting on a synchronization primitive called a turnstile, which is a queue of threads that are blocked on a lock. A common failure mode in complex multithreaded apps is a thread does not release ownership of some asset then the other threads pile up waiting on that. Without source code or more internals info, I can't tell who owns that lock.
There are many audio-related functions in the call stacks of various FCP threads. If this timeline is anything like some of your past demonstrations, you have many audio layers. Maybe there is some interaction between certain audio effects or layers and a multi-monitor system. If you have an easily reproducible scenario, you could try duplicating the project, deleting a portion of the audio lanes and see if it still hangs.
Several threads are blocked waiting for VTDecoderXPCService, which is an XPC service that talks to the decoders that run in a separate sandboxed address space. I don't know if that is a side affect of the hang or if the problem began there.
I'm sorry that is not much helpful analysis. If you have an actual crash, when the FCP crash dialog is raised please copy/paste all that text to a plain text file, e.g, TextEdit with Format>Make Plain Text. Save that as a .txt file and send that to me via the previous URL. Maybe that would be more revealing.