I'm having constant crashing problems with Final Cut Pro. I've tried getting rid of all plugins, taking out external monitors, deleting preferences, unplugging external devices and I'm getting 5-10 crashes per day with seemingly no specific trigger. Sometimes it just quits while I have another application in the foreground ,sometimes I'm clicking through an event and it quits, sometimes I click on the timeline and it quits. I'm about to go into an edit on a very large documentary project and this is getting me very worried. Its not a library specific problem as it happens in any project I'm working on.
I've run apple hardware diagnostics and no problems have been found, and I've done disk utility to the boot drive. I don't have this problem in other applications - but FCP seems to have got much worse since Big Sur.
Any thoughts would be most welcome.
iMac 2017 18.3 - 4.2GHZ. 64GB ram 4TB SSD 10.5.2. 11.4 Big Sur
You may have already done this, but reboot the machine. Make sure you have at least 20% free space on all drives. Also, as a test do not run the Chrome browser. There have been many past problems traced to Chrome, and I don't know if those were ever fixed.
If you have any external video or audio hardware (wireless or not) try disconnecting that. IOW AJA or Blackmagic devices, wireless headphones, etc.
Your description mostly indicates an application layer problem not system layer. However the part about having another app running is suspicious. Run Activity Monitor and check the memory pressure graph under the Memory tab. It should be green.
Make sure all library and media files are on directly-attached drives formatted as either HFS+ (Mac OS Extended Journaled) or APFS.
The FCP crash logs should be in ~/Library/Logs/DiagnosticReports. You can go there in Finder by holding the OPT key and clicking the Go>Library menu. Those are also available by running the Console app and selecting Crash Reports in the left sidebar. You can CMD+A to select all then paste that to a plain text file using TextEdit and attach it to a post -- please do not post in line. I can examine it for clues.
Even though you've removed all plugins, it might be some kind residue from a buggy plugin. Examining the crash log can help isolate that.
It appears that crash log was not for FCP but for a Safari component called com.apple.WebKit.WebContent.
You'll need to get a FCP crash log. If those are not denoted in the previously-listed locations, the next time FCP crashes and raises a crash dialog, select all the text with CMD+A then paste it to TextEdit and save as a .txt file, then upload that.
I'm not familiar with WebKit. Below is all I can gather from the WebKit crash log:
- Time since MacOS boot: 2 days 13 hr (suggest reboot).
- com.apple.ShazamKit (???) Just announced at WWDC as beta? Not sure what that means.
- Large amount of virtual memory (not physical memory) allocated -- 79 GB. Apparently allocated by webkit for Javascipt-related functions...not abnormal by itself but double-check Activity Monitor CPU and Memory tabs. If your main task is just opening a FCP library, no process should be hogging a bunch of CPU and Activity Monitory>Memory>Memory Pressure should be green, not yellow or red. In the memory tab if you sort by the memory column, verify the top memory consumer is not over, say, 10 GB or so.
- Try running your FCP crash scenario without Safari or any other browser running. That means totally shut down so the dock icon has no black dot under it.
FCP crash in thread 40 due to illegal instruction (EXC_BAD_INSTRUCTION). Prior to this it was in the function gpusSubmitDataBuffers. That is a common failure mode when a buggy plugins crashes FCP. Graphics kernel error: 0x067900fc Thread 23: FFAVFMediaReader (any use of media card? If so discontinue).
Numerous plugin items were in FCP memory at time of crash. NOTE: any bug in any plugincan crash or destabilize the entire FCP process. Even if you don't use a plugin in your current timeline, the plugin code can still be in FCP memory.
I noticed plugins from CoreMelt, FxFactory (inc'l CrumplePop). Those are good companies but to rapidly isolate the problem the best procedure is remove them all. You can later re-install if needed, after the immediate situation is resolved. CoreMelt removal tool: support.coremelt.com/hc/en-gb/articles/2...ove-CoreMelt-plugins
Contact the Coremelt folks for help uninstalling/deleting their plugin. If after uninstalling it you're still having issues and Chrome has ever been installed, follow these instructions to completely remove it and the keystone daemons it installs. chromeisbad.com Search the Apple FCP discussions for numerous instances of it breaking Pro Applications.
Besides what Terry said, have you had any MacOS hangs, kernel panics or uncommanded MacOS reboots? I think I recollect a series of similar FCP stack traces on a 2015 or 2017 iMac which was ultimately tracked to an incipient GPU failure. It would also spontaneously reboot itself once a week. The Genius bar had to run overnight bench diagnostics to find it. Later today I will see if I saved those old crash logs. But my top suspicion is a plug-in.
So I've manually gone through and deleted all the core melt plugins at the library level, and FX Factory is un-installed. I've uninstalled Chrome and I've also got rid of the NDI Newtek software. I've also updated Nitrate which was an old version. So far so good - I've not had any crashes since under light use.
I haven't had Kernal panics or the link - not since I stopped using my Caldigit Raid, which used to regularly mean I would hang and kernel panic. Appreciate the help guys -and if it stays stable I'll re-introduce FX Factory and see from there.
I looked through some old FCP 10.4.1 crash logs I had from a 2017 iMac 27. They showed a similar stack trace and I made a note back then I suspected CoreMelt plugins causing it. I remember sometimes it would happen after simply opening a library. I had just gotten an iMac Pro, so when I started hitting those problems instead of troubleshooting it I switched machines.
If it seems stable without the plugins you could carefully re-install the latest versions one at a time with testing in between.
This issue should be greatly reduced as FCP plugins are re-written to use the FxPlug 4 framework which puts them all in a separate address space. FxPlug 4 is mandatory for plugins on Apple Silicon.
If you have external USB storage connected through a USB hub, I suggest you try running without any hub, using only directly-connected storage. Hubs have caused various sporadic problems.
Your system had been up over a week at the time of the FCP crash. Of course that should not be a problem, but you might reboot the machine and see if you can reproduce it after a recent clean start.
If you have not tried creating a new MacOS user account, do that and run your tests from that new account. Various past FCP problems have been related to anomalies with a Mac user account.
In this case thread 1 crashed when tearing down a thread. Threads are started and stopped frequently, and during the teardown all assets associated with the thread are deallocated. During that process it crashed. Since all threads within a process share the same address space, a bug in any thread can crash other threads. Those kinds of problems are difficult to find because the guilty thread doesn't crash, rather it unwittingly places a "booby trap" in the path of another innocent thread.
Looking through some old crash logs I have from 2018 on a 2017 iMac 27 running FCP 10.4.x, some of those had vaguely similar stack traces and seemed related to CoreMelt plugins. However your latest crash dump shows no sign of CoreMelt or any other obvious plugin. In my case the crashes would often happen when I was simply doing regular FCP color correcting using color wheels, color or shape mask, and it seemed more frequent if I had the scopes up.
In case your problem is caused by undetected library corruption, you could try exporting a library XML, create a new library, then load that XML. It should re-create the library, but all the internal event, project and library SQLite databases will be recreated from the XML file. In some cases that filters out library damage.
You could also try running the 3rd-party diagnostic utility EtreCheck: https://etrecheck.com/
@nobbystylus, you didn't say what you were doing when it crashed. If you were attempting to export, there's a 10.5.3 bug affecting some people. Removing all languages other than english and setting the region to US appears to fix it. Lots of discussion about it on the apple discussion board.
Its been happening in 10.5.2 and in previous Big Sur releases sadly. Basically it usually happens when I click on something, either within FCP or clicking to a new window. It quits. Its happening 4 or 5 times a day.
nobbystylus wrote: Its been happening in 10.5.2 and in previous Big Sur releases sadly. Basically it usually happens when I click on something, either within FCP or clicking to a new window. It quits. Its happening 4 or 5 times a day.
Studying your crash logs and any other similar reports, there was a case on 10.4.x where this seemed related to the 3rd-party app CommandPost. Are you running that or have you ever run it? commandpost.io
The sequence in your crash log: a thread was started, then a call made to terminate it (reasons unknown). Any thread can access all assets within the process. When a thread terminates, any data structures, synchronization objects, file handles, memory allocations, etc. must be cleaned up. The subsequent stack frames after the thread exist call indicates it was doing that and attempting to deallocate some GPU assets when it crashed. That's all I can tell from the log. No further targeted analytic steps seem possible, but there are broader corrective steps you can try.
It's suspicious that sometimes FCP crashes when doing no actions within FCP, just clicking on another MacOS desktop window.
You've already tried the initial obvious steps such as resetting FCP preferences, removing all 3rd-party FCP plugins, and I assume removing any USB hubs, external audio/video hardware inc'l wirelesss audio.
If not already done you could try running Apple hardware diagnostics. It's a simplistic test and an error-free pass does not mean a "clean bill of health", but if a problem is found it's significant: support.apple.com/en-us/HT202731
Just as a background step you could run Disk Utility First Aid on all drives, inc'l the system drive. To properly run it should be in Recovery Mode, else it can't get a lock on the drive to make corrective changes. With APFS it must be run twice, once on the system volume and once on the data container.
After that there are several possible steps, in increasing order of difficulty. Fully back up the machine beforehand.
- Re-install FCP.
- Re-install MacOS "in place". That should leave in place all apps and data.
- After doing both a verified Time Machine and Carbon Copy backup, erase the machine, re-install MacOS, then use Migration Assistant to re-load your apps and data. That is more thorough than an in-place MacOS reinstall, but less thorough than a full manual "nuke and pave" reinstall.
- If that doesn't work, the next step is a full "nuke and pave", where you erase the machine, re-install MacOS then manually re-install just the apps, utilities and data you currently need. I know that's a lot of work (I just did it on my main machine), but can fix some intractable problems. If you haven't done that within a few years it needs doing anyway. When I did this I had three backups: Time Machine, Carbon Copy (verified bootable), and a separate folder copy of everything in /Documents, /Downloads, /Applications, /Public, etc.