Describe the Bug:
Final Cut Pro frequently experiences a permanent main-thread hang (spinning beachball) upon launch when restoring multiple libraries from a previous session. Once this hang occurs, the application becomes permanently blocked; attempting to open any library (even completely different, healthy ones) will trigger the exact same hang.
Standard troubleshooting steps—like deleting the macOS savedState directory or forcing a blank launch via the Option key—do not resolve the issue. The deadlock state is serialized directly into the main preference domain (com.apple.FinalCut.plist). The only way to restore application functionality is a total preference destruction (defaults delete com.apple.FinalCut), which severely disrupts user workflows by wiping out all custom shortcuts, import settings, and destinations.
Expected Behavior:
Final Cut Pro should asynchronously queue and restore previously open libraries without stalling user interaction or deadlocking the main UI thread.
Actual Behavior:
FCP freezes entirely. The system diagnostic logs reveal a permanent main-thread deadlock where the user-interface thread is trapped waiting on asset/thumbnail rendering tasks executing on background queues.
System Environment & Specifications
• Final Cut Pro Version: 12.2 (Build 447037)
• macOS Version: macOS 26.5 (Build 25F71)
• Hardware Model: Mac Studio Ultra (Mac13,2 - 20 CPU Cores)
• Memory: 128 GB RAM
Log Analysis / Stackshot Excerpt
The heaviest stack on the main thread demonstrates that FCP's document controller blocks the thread while attempting to update project thumbnail visual layers for the Filmstrip/Organizer module during the layout restoration step:
19 -[PEAppController restoreOpenDocuments] + 100 (Final Cut Pro + 240412) [0x104786b1c]
19 -[FFWorkspace restoreActiveDocuments:mustRestore:error:] + 300 (Flexo + 14492288) [0x10d6fe280]
19 -[FFWorkspace restoreDocuments:urls:mustRestore:] + 376 (Flexo + 14491548) [0x10d6fdf9c]
...
19 -[FFOrganizerFilmstripModule _restoreProjectRelatedSelectionStates] + 60 (Flexo + 1871452) [0x10caf4e5c]
19 -[FFOrganizerFilmstripViewController restoreProjectSelectionAndPersistentPlayheadPosition:] + 1660 (Flexo + 8280808) [0x10d111ae8]
19 -[FFOrganizerFilmstripView _reflowChunks] + 1896 (Flexo + 5087344) [0x10ce06070]
19 -[FFOrganizerProjectChunk updateProjectThumbnailLayer] + 152 (Flexo + 12429308) [0x10d5067fc]
19 -[FFSequenceInfo requestThumbnailImageForQuality:addThumbnailToEvent:removeTitles:completionBlock:] + 396 (Flexo + 7458992) [0x10d0490b0]
19 -[FFSegmentReadSample waitForState:enablePriorityInherit:why:beforeDate:] + 1164 (Flexo + 950200) [0x10ca13fb8]
19 __psynch_cvwait + 8 (libsystem_kernel.dylib + 17676) [0x187a8d50c]
Root Cause:
The log shows the main UI thread trapped in __psynch_cvwait via FFSegmentReadSample waitForState:. Because a total preference wipe is required to resolve the hang, FCP is clearly writing a corrupted layout or state serialization flag directly into com.apple.FinalCut.plist before shutdown. On subsequent launches, FCP reads this bad preference data, attempts to initialize the UI/Filmstrip layers based on it, and immediately deadlocks the background asset threads. Because this happens at the core preference level, it poisons the global application state, causing every subsequent library load to fail until the plist is deleted.
1. Decouple UI Drawing from Document Loading: The application launch state routine (restoreActiveDocuments) should execute completely asynchronously from primary UI render loops. FCP should draw the interface framework instantly rather than blocking the main thread waiting for library database objects to resolve.
2. Asynchronous/Lazy Thumbnail Population on Launch: Rather than calling a blocking waitForState: request during an application launch sequence, the Filmstrip module (FFOrganizerProjectChunk) should display a lightweight placeholder visual generic asset. The background asset-reader threads can then lazily populate the actual thumbnails after the library file handshake is completed.
3. Enforce hard Timeouts inside App Initialization Blocks: -[FFSegmentReadSample waitForState:... beforeDate:] should respect a strict, short expiration timestamp if called globally by the App Controller during startup. If the asset queue fails to return a pixel buffer within 500ms, it must safely break out of the condition loop, skip the specific thumbnail render layer, and maintain application responsiveness instead of locking up the system thread structure indefinitely.
Describe the Bug:
Final Cut Pro frequently experiences a permanent main-thread hang (spinning beachball) upon launch when restoring multiple libraries from a previous session. Once this hang occurs, the application becomes permanently blocked; attempting to open any library (even completely different, healthy ones) will trigger the exact same hang.
Standard troubleshooting steps—like deleting the macOS savedState directory or forcing a blank launch via the Option key—do not resolve the issue. The deadlock state is serialized directly into the main preference domain (com.apple.FinalCut.plist). The only way to restore application functionality is a total preference destruction (defaults delete com.apple.FinalCut), which severely disrupts user workflows by wiping out all custom shortcuts, import settings, and destinations.
Expected Behavior:
Final Cut Pro should asynchronously queue and restore previously open libraries without stalling user interaction or deadlocking the main UI thread.
Actual Behavior:
FCP freezes entirely. The system diagnostic logs reveal a permanent main-thread deadlock where the user-interface thread is trapped waiting on asset/thumbnail rendering tasks executing on background queues.
System Environment & Specifications
• Final Cut Pro Version: 12.2 (Build 447037)
• macOS Version: macOS 26.5 (Build 25F71)
• Hardware Model: Mac Studio Ultra (Mac13,2 - 20 CPU Cores)
• Memory: 128 GB RAM
Log Analysis / Stackshot Excerpt
The heaviest stack on the main thread demonstrates that FCP's document controller blocks the thread while attempting to update project thumbnail visual layers for the Filmstrip/Organizer module during the layout restoration step:
Root Cause:
The log shows the main UI thread trapped in __psynch_cvwait via FFSegmentReadSample waitForState:. Because a total preference wipe is required to resolve the hang, FCP is clearly writing a corrupted layout or state serialization flag directly into com.apple.FinalCut.plist before shutdown. On subsequent launches, FCP reads this bad preference data, attempts to initialize the UI/Filmstrip layers based on it, and immediately deadlocks the background asset threads. Because this happens at the core preference level, it poisons the global application state, causing every subsequent library load to fail until the plist is deleted.
1. Decouple UI Drawing from Document Loading: The application launch state routine (restoreActiveDocuments) should execute completely asynchronously from primary UI render loops. FCP should draw the interface framework instantly rather than blocking the main thread waiting for library database objects to resolve.
2. Asynchronous/Lazy Thumbnail Population on Launch: Rather than calling a blocking waitForState: request during an application launch sequence, the Filmstrip module (FFOrganizerProjectChunk) should display a lightweight placeholder visual generic asset. The background asset-reader threads can then lazily populate the actual thumbnails after the library file handshake is completed.
3. Enforce hard Timeouts inside App Initialization Blocks: -[FFSegmentReadSample waitForState:... beforeDate:] should respect a strict, short expiration timestamp if called globally by the App Controller during startup. If the asset queue fails to return a pixel buffer within 500ms, it must safely break out of the condition loop, skip the specific thumbnail render layer, and maintain application responsiveness instead of locking up the system thread structure indefinitely.