FCP 11.0 – 11.1.1: Crash with model‑locking assertion if RED RAW Inspector changes are applied during certain background tasks

[joema4]

Apple Feedback Assistant ID: FB19796095

DESCRIBE THE BUG:

Crash when retiming during playback with RED RAW HUD open and changes are applied. Crash is actually a model‑locking assertion: _FFModelLocker, libraryLock == nil)

This is a regression in 11.x: Background‑task coordination for RED RAW changes moved out of the controller into a dedicated warning/coordination path. Locking switched from a global model lock to per‑library locking, via _FFModelLocker, which requires a non‑nil LibraryLock.

Failure mode: Race condition between background action and RED RAW HUD update. During playback + retime + RED RAW HUD, the set of “anchored” assets (IOW connected clip or secondary storyline) can change just before the lock is acquired. The code dereferences an asset to obtain LibraryLock, but gets nil, and asserts. Other background actions besides retiming with optical flow may also cause this, but this specific scenario was reproducible.

TO REPRODUCE:

• See materials on https://www.dropbox.com/scl/fo/fh5ufjinlfmsuopwzqj9e/AGX97-yfPLk7NfE7WMUAZWY?rlkey=1bhkl1mbjulkg69ime3186dz9&st=h4f2nww3&dl=0

• If needed, install Apple RED Workflow: https://www.red.com/download/red-apple-workflow-installer

• Turn off background render: FCP Settings>Playback>Background render - Off

• Put the two attached R3D clips on timeline, top clip overlapping
  the bottom clip about 50%

• Use attached project XML R3DTestProject.fcpxmld, then relink to clips

• If XML or relink doesn't work, just do steps manually.

• Bottom clip: retime ~110% with Optical Flow, Stabilization on.

• Top clip: Stabilization on.

• Set Blend Mode = Screen to force both layers to render.

• Show background tasks (CMD+9)

• Wait for optical flow analysis to finish.

• Start playback in Loop Mode (CMD+L)

• Open RED RAW Settings (HUD/Inspector) for either clip.

• Make change to RED RAW settings and Apply.

• While still playing, Modify > Retime > Custom, enter a new percentage, confirm.

• Repeat RED RAW Settings change

• Repeat Modify > Retime > Custom, enter a new percentage.

• Repeat above two steps until it crashes (normally within 1-2 minutes).

---

EXPECTED BEHAVIOUR:

_FFModelLocker > FFAssertionHandler > background‑task warning for assets > invoked by
RED RAW settings flow > UI action.

• See attached FCP crash logs
• See attached log show files

Log Show Excerpts and Interpretation:

ASI found [Flexo] (sensitive) 'Invalid parameter not satisfying: libraryLock != nil … FFModelLocking.mm:264'

– Assertion failure in FCP (Flexo framework): This line indicates that Final Cut Pro triggered an internal
assertion (NSAssert) in its Flexo framework. The message shows that a library lock object was unexpectedly
nil, which violates an expected condition in FCP’s code (see FFModelLocking.mm:264). This is likely the
root cause of the crash: the application hit an unexpected state (a missing library lock) and raised an exception.

'*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid parameter not
satisfying: libraryLock != nil … FFModelLocking.mm:264''

– Uncaught exception due to the failed assertion: This log (from CoreFoundation via ReportCrash) confirms that
the app was terminated because of an uncaught NSInternalInconsistencyException. The exception’s reason mirrors
the assertion above, explicitly stating the failure (libraryLock != nil not satisfied). In short, Final Cut Pro
threw an internal inconsistency exception when it detected the missing library lock, leading to a forced
termination since the exception was not handled.

ASI found [libsystem_c.dylib] (safe) 'abort() called'

• This line shows that the process called abort(), which is consistent with an app terminating itself after
  an unhandled critical exception. In Final Cut Pro’s case, the failed assertion/exception above triggered
  an abort. This confirms the app crash occurred at that moment – the runtime halted the process deliberately
  because of the inconsistency. It underlines that the crash was intentional (abort due to assert) once the
  error condition was detected, rather than a slow memory death or external kill.

Comments on above three log show messages:

Each of these log excerpts points to the same failure mode: Final Cut Pro encountered an
unexpected nil libraryLock (likely a synchronization or project library issue), asserted internally,
and then crashed with an NSInternalInconsistencyException.

---

SPECS:

• Final Cut Pro 11.0 – 11.1.1 (not seen on 10.8.1)
• Apple Silicon (e.g., Mac Studio M1 Ultra), M1 Max MacBook Pro 16, macOS 15.6
• No proxies/optimized media, Background Rendering off
• Apple Silicon, macOS 15.x
• Hardware: M1 Ultra Mac Studio, also reported on other machines
• Media: R3D (8K/6K in our repros)
• Project conditions: no proxies or optimized media, background rendering off
• Apple RED Workflow version 22.0.0

---

ADDITIONAL COMMENTS:

• Regression window: Begins in 11.0. Not observed in 10.8.1.

• Details of relevant change from 10.8.1 to 11.x:

  • Background‑task coordination for RED RAW changes moved out of the controller into a dedicated warning/coordination path.
  • Locking switched from a global model lock to per‑library locking via _FFModelLocker (requires non‑nil libraryLock).
  • Failure mode: During playback + retime + RED RAW HUD, the set of “anchored” (ie connected clip or connected storyline) assets
    can change just before the lock is acquired; the code dereferences an asset to obtain libraryLock, but gets nil, and asserts.

• Background activity involved: Stabilization and Optical Flow analysis are active at the time of the crash (Helium/graph threads).
  The guard path may not fully synchronize with these analysis tasks in this interaction.

What helps repro:

• Keep playback running; repeatedly change retime with the RED RAW HUD open.

• Change RED RAW settings repeatedly.

• Use Optical Flow retiming + Stabilization on at least one clip (both improves hit rate).

• Force both layers to render (e.g., Screen blend).

• Lower‑memory systems or simulated memory pressure tend to increase repro rate (background tasks run longer).

• If needed, use the XCode command line utility memory_pressure to increase memory stress for 90 sec:

  sudo memory_pressure -S 90 -l critical

• Instruments memory traces shows this is not a memory leak issue, but memory stress may
  hasten the problem.

Mitigation (user‑level, temporary)

• Stop playback before retiming or before clicking Apply in RED RAW HUD.
• Wait for Background Tasks to settle when heavy analysis is active.

Debugging Suggestions:

Add lightweight logs/breakpoints around the background‑task warning path used by RED RAW changes:

• Just before constructing _FFModelLocker: log assets count / IDs and whether libraryLock is nil.
• If assets become empty or libraryLock is nil at that point, re‑validate the asset snapshot under a read lock or retry.
• Ensure stabilization/optical‑flow analysis is treated as “blocking” for this path; prevent auto‑restart of tasks in the pause/cancel window.

Details about 10.8.1 to 11.x change that may have caused this:

Framework: Flexo

FFREDRAWSettingsController

• 10.8.1: Inlined the “are background tasks running?” gating + purge flow. Used global model lock (FFSharedLock, read>write)
  when purging/committing changes.

• 11.x: Delegates the gating/purge flow to a separate background‑task warning/coordination path (see below). Callers still go
  through +verifyNoRunningBackgroundTasksForAnchoredObjects: but the heavy lifting moved out.

• FFChangeAffectsTranscodedMediaWarning (new in 11.x)

  • Provides the background‑task check + warn + cancel/pause + purge sequence for camera/RAW changes.
  • Key step: derives a per‑library lock via [[assets anyObject] libraryLock] and then
    constructs _FFModelLocker (RAII) to guard purgeTranscodedMedia.
  • Also expanded alert timing: can present the “transcoded media will be invalidated” dialog even
    when only render/transcode tasks are active, lengthening the window between pause and lock/purge.

• Locking model

  • 10.8.1: Global model lock (FFSharedLock) around purge/commit.
  • 11.x: Per‑library lock via _FFModelLocker, sourced from the first asset’s libraryLock.
    This makes correctness depend on the asset snapshot being valid at lock time.

• Background task detection

  • Both versions explicitly handle render/transcode tasks; in practice, stabilization/optical‑flow
    analysis (Helium/Graph) may not be treated as “blocking” by this path, enabling overlap during playback/retime.

Failure mechanism:

Crash is a deliberate assertion (SIGABRT, not OOM/SIGSEGV/SIGTRAP/SIGBUS):
NSInternalInconsistencyException — “Invalid parameter not satisfying: libraryLock != nil”
in _FFModelLocker. During playback + retime with the RED RAW HUD open, the background‑task
coordination path is invoked; anchored objects/assets may change right before lock acquisition
(retime and/or analysis threads), so [[assets anyObject] libraryLock] is nil and the assertion fires. 10.8.1’s
global lock + shorter, inlined flow exposed a smaller race window; 11.x’s delegated flow +
per‑library lock + longer alert/coordination window makes the race reproducible.