Constant crashing with FCP, even when it starts up

I studied closely the crash at 2024-11-24 02:24:31.7253 -0700, but they are all similar.

Thread 44 crashed in OZFxPlug_GetFlexoInputNode due to dereferencing a null pointer. OZ=Ozone, the FCP private framework that implements the Motion runtime engine and effects processing.

This crash appears to be a complex interaction between FCP's effect system, background processing, and resource management. The root cause may be a synchronization loophole (e.g, race condition) between effect processing and thumbnail generation.

However if we look earlier in the stack trace (around frame 77) we see an an exception occurred in the background task. Instead of properly handling it, the code continued execution, apparently without cleanup or (maybe) not even logging it.

This led to corrupted state that caused the scheduling system to enter an infinite recursion.

Finally, after corrupting the stack, it attempted to access an invalid pointer and crashed.

The effects thumbnail generation logic is complex. There is a background task queue ("effectLibraryThumbnailGenerator") for processing. It has both a memory cache (FFObjectCache) and disk cache (FFSegmentStoreRef).

An obvious question is why now, and why only on your machine? Unknown. Because of the track record of CoreMelt causing problems, and the failure of their uninstall tool to fully work, I suggest you manually remove all traces of that (as a temporary test). They have a support page with the procedure: https://support.coremelt.com/hc/en-gb/articles/360013189594-Where-are-files-from-CoreMelt-installed-How-to-manually-uninstall

If you have any other third-party Fx, especially those from Pixel Film Studios, please list those.

If that doesn't help, the next time the crash happens run the following terminal command which gathers FCP-specific logging info, then upload that so I can examine it.

log show --info --debug --predicate 'processImagePath CONTAINS "Final Cut Pro"' --last 1h > ~/Documents/Redifer_FCP_Log.txt 

Delete all cache, proxies, optimized media and magnetic mask files:

1. Select library in left side bar
2. File>Delete Generated Library Files>Delete Render Files>All, also select checkboxes for Delete Optimized Media, Delete Proxy Media, and Delete Unused Magnetic Mask Files

If it still happens:

1. Export a library XML
2. Shut down FCP and make a file-level backup of the entire library

Then launch FCP and select the project in the left side bar, press the OPT key, and select Clip>"Verify and Repair Project". Take a screenshot of any messages.

If there are still problems, create a blank library and load the library XML you made. Take a screenshot of any errors during the XML load.

Test your workload on the new library created from the XML. Does that work?

If FCP still crashes, please gather all the FCP crash logs with a .ips file extension from the below locations and upload to a file sharing service I can access.

/Users/YourUserName/Library/Logs/DiagnosticReports/

/Users/YourUserName/Library/Logs/DiagnosticReports/Retired

joema wrote:

Joe, after further study of your trace, it shows evidence of a "thread explosion," whereby hundreds of threads named CVDisplayLink are generated but do nothing. This happens roughly coincident with your drag/drop operation, but I can't tell if that is the cause. Once it enters that state, FCP is unstable and behaves unpredictably. That likely explains the vague "No other information" error message. That also explains why restarting FCP is required.

I tend to think this isn't a hardware or config issue. It is more likely an FCP bug, maybe triggered by a plugin or other yet-unknown factor.

How often can you reproduce it using the Gaussian Blur drag/drop? Does that particular action seem to trigger it more than others?

I did several tests dragging combinations of Gaussian Blur and Drop Shadow on a partially transparent PNG and never saw any problems.

We know "DisplayLink" as the software that is used with many third party docks to support displays, at times in excess of what some mac models support natively.

This does not seem to be a coincidence...

Joe, I've spent lots of time examining your 60-second Instruments trace. I can clearly see the "soft freezes", or UI hangs in FCP. However the onset of the underlying problem happens before those manifest. Even in the first part of the trace, FCP is already malfunctioning. The indicator within the Instruments trace is a "thread explosion" of 100+ CVDisplayLink threads (normally there should just be a few). This evidently happens before the UI hangs start occurring.

I have written a script to detect this CVDisplayLink problem, automatically halt the XCTrace command, then signal you with a beep that it happened. Then you could send me that trace and it would be closer in time to the internal failure process. However I need to first test it. Maybe tonight or tomorrow I'll upload it.

The crash log was in .ips format so I had to write a Python script to interpret it. The stack trace of the crashing FCP thread is below. This implies the crash was caused by a color-related FxPlug plugin, and happened when handling On Screen Controls.

Does that ring any bells?

Crash Report

========================================

Date/Time: 2024-12-06 21:12:00.00 -0700

Application: Final Cut Pro

Version: 11.0

Build: 430149

Bundle ID: com.apple.FinalCut

OS Version: macOS 15.1.1 (24B91)

Process Information

----------------------------------------

Process Name: Final Cut Pro

Process Path: /Applications/Final Cut Pro.app/Contents/MacOS/Final Cut Pro

Process ID: 12464

Launch Time: 2024-12-06 00:16:06.6933 -0700

CPU Type: ARM-64

Exception Information

----------------------------------------

Exception Type: EXC_CRASH

Exception Codes: 0x0000000000000000, 0x0000000000000000

Termination Code: 6

Termination Reason: SIGNAL

Terminated By: Final Cut Pro (12464)

Thread Information

----------------------------------------

Crashed Thread Stack Trace:

38400: __pthread_kill + 8

28528: pthread_kill + 288

497928: abort + 128

14909916: FFApplicationHandleExceptionThatShouldNotBeIgnored.cold.1 + 156

10332984: FFApplicationHandleExceptionThatShouldNotBeIgnored + 196

1669388: __handleUncaughtException + 816

152536: _objc_terminate() + 144

75536: std::__terminate(void (*)()) + 16

89996: __cxa_rethrow + 204

262676: objc_exception_rethrow + 44

81392: -[FFFxPlugEffect(CustomParameterAction) currentFxTime:] + 220

878128: -[PAEColorSelectionOSC _readOSCParameter:time:] + 80

878404: -[PAEColorSelectionOSC drawOSC:height:activePart:atFxTime:] + 208

60992: -[FFFxPlugOSC drawRect:toContext:drawProperties:] + 724

2289392: -[FFPlayerVideoModule drawOSCsAtTime:inRect:drawDestination:drawProperties:isDisplaying:] + 1864

2246980: -[FFPlayerVideoModule didDrawVideoAtTime:drawDestination:drawProperties:isDisplaying:] + 80

97548: -[FFMetalVideoPainter newOSCDrawTextureAtTime:viewSize:delegate:drawProperties:destIsDrawing:filmToViewTransform:backingScale:] + 380

11089056: -[FFDestVideoDisplay newOnScreenControlsTextureForFrame:atTime:drawProperties:isDisplaying:] + 484

5131852: -[FFPlayerScheduledData generateOverlayInfo:currentTimecodeType:] + 744

551524: -[FFPlayer _generateOverlayTextures:rate:] + 372

586360: -[FFPlayer _renderVideo] + 6324

592036: -[FFPlayer idle] + 148

516720: -[FFPlayer playerRenderThreadMain:] + 920

345908: __NSThread__start__ + 724

29412: _pthread_start + 136

8444: thread_start + 8

Joe, I spent more time examining the Instruments trace you took. Another thing I previously missed was the audio threads in FCP are behaving abnormally. The stack traces from those threads are 100 calls deep, and take from 200 mS to 1.4 seconds. That level of recursion is problematic because audio processing needs to be real-time. Each audio buffer needs to be processed within its duration (typically 2-10ms) to avoid audio glitches.

Maybe it was doing that because FCP had already become deranged when you took that trace. Are you using any FCP audio plugins or any type of notable audio processing that could affect FCP?

Joe, after further study of your trace, it shows evidence of a "thread explosion," whereby hundreds of threads named CVDisplayLink are generated but do nothing. This happens roughly coincident with your drag/drop operation, but I can't tell if that is the cause. Once it enters that state, FCP is unstable and behaves unpredictably. That likely explains the vague "No other information" error message. That also explains why restarting FCP is required.

I tend to think this isn't a hardware or config issue. It is more likely an FCP bug, maybe triggered by a plugin or other yet-unknown factor.

How often can you reproduce it using the Gaussian Blur drag/drop? Does that particular action seem to trigger it more than others?

I did several tests dragging combinations of Gaussian Blur and Drop Shadow on a partially transparent PNG and never saw any problems.

There is some plugin causing your crashes. Use the complete CoreMelt uninstaller tool. Google "Download CoreMelt remove everything tool" and use that. Then reboot the machine and see how it works. If FCP crashes, upload those new crash logs and I'll examine them.

The XML load problem is somehow related to clips with Drop Frame timecode. Post a link to that complete XML and I'll examine it.

Redifer, the below procedure will capture an Instruments trace of your FCP soft-freeze which I can analyze:

1. Install XCode from App Store. It is free.

2. During installation, answer 'yes' to installing XCode command line tools, if it asks.

3. After it's installed, verify that xctrace is working from the terminal command line. Just type 'xctrace' and a return. It should print a few lines of syntax help.

4. Create a folder named "tracelogs" in ~/Documents to receive the Instruments trace file.

5. Launch FCP and get it ready to reproduce the problem.

6. From terminal, type this command (replace with your own home folder): sudo xctrace record --attach "Final Cut Pro" --window 30s --template "Animation Hitches" --output /Users/<YourHomeFolder>/Documents/tracelogs

7. Enter your Mac password if asked. It will indicate when it begins tracing.

8. You need not hurry, as it's configured to only save the last 30 sec before you abort tracing via CTRL+C on the command line.

9. Reproduce the FCP soft-freeze problem.

10. Immediately after reproducing it, switch to the terminal and enter CTRL+C. It may take a minute to finish writing the trace file in ~/Documents/tracelog.

11. Upload that trace log to a file sharing location I can access.

Joe: I am still working on this. Just this morning, I might be able to reproduce the "runaway CVDisplayLink" problem on a different project.

You previously said sometimes FCP would just crash and disappear. Can you send me any of the FCP crash logs? They usually have an .ips file extension and are in the below locations. However I'm interested in any files which contain "FCP" or "Final Cut" in the filename. Upload them to a file-sharing service I can access.

/Users/YourUserName/Library/Logs/DiagnosticReports/

/Users/YourUserName/Library/Logs/DiagnosticReports/Retired

I defer to Joema's deep experience in this, but if FCPX Artist Brush is the Pixel Film Studios FCPX Brush, I would suspect it since PFS doesn't have a great developer reputation. I'd completely uninstall both and see if things improve.

Terry, this is a complex area. I worked in software development and escalation support for years and it's still hard. Ideally you want a "block diagram" conceptual overview of FCP and the private frameworks, but there is no documentation for that. I've gradually learned that over the years. Some of the fundamental FCP concepts are covered in US patent US8875025B2, which is available online.

In Redifer's case it might be a plugin but it's not clear. Some internal effects also use the FxPlug interface. The simple answer is search for "FxPlug" in the crash log, but this by itself doesn't mean much.

List FxPlug plugins: pluginkit -m -p FxPlug

List more info about a plugin (for example): pluginkit -mv -p FxPlug | grep "NeatVideo"

Apple info on analyzing a crash log: Analyzing a crash report | Apple Developer Documentation

FxPlug SDK: FxPlug | Apple Developer Documentation

WWDC18: "Understanding Crashes and Crash Logs"

Gathering info via the MacOS log commands: "Mac Logging and the log Command"

WWDC19: "Getting Started with Instruments"

Diagnosing issues using crash reports and device logs | Apple Developer Documentation

Debugging MacOS apps: Debugging | Apple Developer Documentation

I can see the hangs but it's difficult to backtrack to the root cause. There is an FCP thread showing some odd audio activity. If your system has any external audio or video devices or a second monitor, can you try disconnecting all of that and see if it makes any difference? If you have a single monitor, what type and how is it connected?

Also please look in Activity Monitor's CPU tab under the "kind" column. We want to make sure FCP has not been inadvertently launched under Rosetta. The "kind" should be "Apple", not "Intel".

That "soft-freeze" behavior is not one we've ever experienced (knock-on-wood). Have you tried taking the Acasis enclosure out of the equation for testing?