FCP crashing with Red Komodo when modify Red RAW Settings

It may be a race condition where the Inspector needs to change clip metadata that would invalidate transcoded media (RAW / REDRAW, LUT, color space, etc.). Before it does, it calls verifyNoRunningBackgroundTasksForAnchoredObjects to make sure no background tasks (transcoding, analysis, asset‑copy) are touching those assets.

If a background task thread hasn’t quite released the FFSharedLock when that call is made, that's considered a serious code issue, so an assertion fires and crashes FCP. I don't understand why they do that, but that appears to be the case. I might be able to reproduce this, but I won't have time to work on it for several days.

In the meantime, try these workaround steps:

• In FCP>Settings>Playback, disable background render if it is enabled.
• Delete all existing optimized/proxy media.
• Only do manual rendering via selecting clips and CTRL+R.
• Do not adjust any RAW metadata while rendering or any other background task is running. This might apply to making any metadata changes in the Inspector; I'm not sure.
• Do CMD+9 to verify no background tasks are running before adjusting anything in Inspector.
• If problems persist, relaunch FCP before making RAW adjustments. If there are orphaned locks, that might clear them.
• Make sure the FCP library is on a fast local SSD, not a spinning drive or network drive. That may reduce a timing window related to the problem.
• It is conceivable the problem happened sometime between 11.0 and 11.1.1, but I'm not sure. If nothing else works, you could try reverting to 11.0 and see if that helps.

Let me know the results of these tests.

wohlford, do you ever get a warning about "background tasks that are not yet complete?" Do you use optical flow or machine learning retiming, stabilization or magnetic masks? You've said you never transcode to either proxies or optimized media, but analysis of your crash files implies the failure mode involves these areas:

• When changing the R3D RAW settings, FCP is checking for some kind of background task, and it believes the R3D change may affect running background tasks. It might be erroneously determining that, but we need to verify whether any effect on your system is involved.
• This check was not done on 10.8.1, it was added in 11.x, apparently in an attempt to use finer-grained locking to improve parallelism.
• After FCP thinks some background task is running, it attempts to acquire a shared library lock, during which it encounters some kind of inconsistency and raises an assert, which crashes FCP.

You are adjusting the RAW settings on an R3D clip. Is that clip on the primary storyline, or is it a connected clip or on a secondary storyline? The code path implies it might be one of those.

Are you using a video output device such as AJA or Blackmagic? Are you using "temporal" effects such as Neat Video, Hawaiki Keyer, Color Finale, or any by CoreMelt? There's nothing wrong with any of those, per se. However, they could be injecting some delays or background tasks that create the conditions for your crash. If we could determine one of those is involved, I'd have a better chance of reproducing this.

I can now easily reproduce this using this procedure:

• Use two layered R3D clips, about 50% overlap
• Change compositing mode to "screen"
• Stabilization on both clips
• Retime the bottom clip with optical flow
• During playback, have the RED RAW menu up, make changes and apply
• Adjust the retiming amount on the bottom clip. If needed, repeat above step and this step until crash.

This doesn't mean it's related to optical flow, rather it's a timing issue that involves the RED RAW menu and a check done for background tasks. Starting with 11.1.1, there is a small window where this could happen.

Failure mode: The crash is a race condition between the UI‑initiated RED RAW changes and concurrent background analysis / graphics work, for example (stabilization + optical flow) during playback and retiming. There are probably other scenarios involving the RED RAW menu that could cause this.

I'll be filing a bug using the MacOS Feedback Assistant app, plus I'll mention it to FCP support.

I was editing RED footage yesterday on 11.1.1 and had no problem. Please send me your FCP crash logs to the below secure write-only WeTransfer site. I will analyze them. The application crash logs are here: ~/Library/Logs/DiagnosticReports or ~/Library/Logs/DiagnosticReports/Retired. The filenames will contain "Final" and may have an IPS file extension.

https://we.tl/r-TcS67o1ccB

I finally managed to reproduce this, but it took over 100 attempts. Are you changing the RED RAW settings during playback, or is playback halted? Please use Activity Monitor to examine FCP memory consumption just before you think it might crash. Use your best judgment. Tell me those numbers. In the Activity Monitor "Memory" tab, for the Final Cut Pro process, tell me Memory, Real Mem, Private Mem, Shared Mem, and VM compressed.

It might reduce the frequency of FCP crashes if you stopped playback before clicking "apply" in the RED RAW adjustment panel. If there are *any* background tasks -- stabilization, optical flow, retiming, magic mask, rendering to cache, etc, those can make it more likely. If you wait for those to finish, that may help.

Aside from that, we can only wait for an update.

turning off Auto-render did help for me. Although another issue I'm getting more and more is that the RED files are going all black more often and I have to restart FCPX to fix the issue.

Did you update 10.x to 11.0 or go from 10.x to 11.1? What were the before/after versions? Knowing the exact versions can help narrow down the problem.

Thanks for sending so many crash logs. Better too many than too few. To expedite getting you a preliminary response, I only studied the four most recent. However, I will now examine the older ones. The four most recent ones show a consistent internal failure mode.

Edit/add: I just looked through the older ones. Because you're having so many crashes, the oldest one is only 17-July, but it shows the same failure mode.

Are you doing any roughly consistent UI action when it crashes? Is it usually when adjusting something in the Inspector (not just RAW), or does it ever happen when just trimming or manipulating the timeline, exporting, importing, etc? If there's any doubt, make a note of the last few steps taken each time it crashes.

I'm having the exact same issues for almost a year now. I'm going to try and turn off auto-render and see if that helps. Definitely happening in adjusting the raw RED footage settings.

Further study shows there may have been some changes from 10.8.1 to 11.0 about how R3D is handled. It might have created a race condition with a thread in the MIO private framework. I'm not sure and will have to study this further tomorrow. I tried pretty hard today to make it crash. So far, it has not happened. I have some other ideas and will pursue this tomorrow.