FCPX Crashing When Exporting

Hello everyone, hopefully someone will be able to help me with an issue I've had for months.  When exporting any video longer than about 1 min, the program crashes.  I add the crash report to this post.

The report says Thread 33 crashed. That thread talks about the cache. Have you cleared the render cache?

Select the library in the browser, choose File->Delete Generated Library Files... Choose All Render files.
support.apple.com/guide/final-cut-pro/ma...iles-ver68a8c250/mac

Yes, I cleared the render cache.

@ASlateMusic, thanks for providing the crash log. Beyond what Terry mentioned, nothing jumps out to me as an obvious cause... (not saying it should, either)

Instead of first asking a bunch of questions, and since you're having trouble with relatively short projects exporting, would you mind creating a new Library with one Event and as simple a test Project as possible (with all media set to be stored in the Library), zip the Library and post it where we could download it and do some testing? Of course, you'd want to make sure this test Library and its Project don't export properly...

Other than that, I'd try rebooting into Safe Mode, following these instructions:

Start up your Mac in safe mode - Apple Support

After booting into Safe Mode, log into your account, then restart normally.

Clear all render/temp "Cache" files, as Terry suggested.

I'd also suggest that you look that the free space on your internal/boot drive, as well as any other drive you're using. You should have over 20% free. All drives should be APFS formatted if they're SSDs, and HFS+ (journaled) formatted (with GUID partition map) if regular spinning hard drives.

Thank you all for taking the time to help.  The issue was the Drifting generator I was using.  The program did not crash when I removed this item.  Is there a way to get the export to work with the generator?  It's a generator that comes with the FCPX program.

ASlateMusic wrote:

Thank you all for taking the time to help. The issue was the Drifting generator I was using. The program did not crash when I removed this item. Is there a way to get the export to work with the generator? It's a generator that comes with the FCPX program.

I just added a "Drifting" generator to a 5 minute timeline and it exported just fine (ProRes422). Have you tried exporting into different formats? I'm on an Intel Mac but using FCP 10.6.5 and macOS 12.7. The generator does significantly increase the export time for my test timeline.

If you were to create a sample/test Library with a Project just over a minute long that exhibits the issue with that generator, you could share the Library so that we could see if the same behavior happens on our systems.

I'd suggest you try the other things I mentioned, as the Drifting generator could need more memory and drive space for processing than a timeline without it. And, let us know about your available drive space on your internal drive, as well as any external drives you're using.

Do you have other crash log files (since you mentioned that this has been happening repeatedly for a while)?

I completed the safe mode reboot. Cleared the cache for the render files. I'm using 116.23 GB of 2.12 TB in storage(internal).  I am not using an external drive.  I'm using an Intel Mac with FCP 10.6.10 and macOS Ventura 13.6.  This project still caused the program to crash.  The file I was exporting was 3:12, and I was exporting as a computer file (mp4).  I also attempted to export as with ProRes422 (mov) with the same result.  

A test Library is attached with just the Drifting generator.  This one crashed the program also.

I do not have the other crash reports.

Most likely, you'll need to compress/zip the Library file in the Finder and provide that via Dropbox, or something similar (there's a limit for posting files here). It appears that you posted an XML file. I'm running FCP 10.6.5 and it isn't compatible with my version of FCP. Someone else will need to test this, or a Library (if you upload one). I wouldn't be able to test an acutal Library file, either, as the Library format has changed at least once in the versions after 10.6.5. Sorry. Thanks.

ASlateMusic wrote:

... I'm using an Intel Mac with FCP 10.6.10 and macOS Ventura 13.6. This project still caused the program to crash. The file I was exporting was 3:12, and I was exporting as a computer file (mp4). I also attempted to export as with ProRes422 (mov) with the same result...

I was just able to reproduce this on a 2017 i7 iMac 27 using your simple project XML. Thank you very much for narrowing that down. I tried several times to reproduce it on my M1 Ultra Mac Studio, without success. However after an apparently successful export, FCP on the M1 Ultra hung trying to shut down. I did a spindump and the stacks were similar to the crash scenario. Both machines were running Ventura 13.6; the M1 Ultra was running FCP 10.6.9 and the i7 iMac 10.6.10. 

So even though the failure mode was different between Apple Silicon and Intel, the problem seems to affect both CPU/GPU types.

There is definitely a problem here. The crashing thread has a very deep stack trace involving various graphics functions. The Ozone framework is the Motion runtime engine. The 'Drifting' generator is a complex effect that can be computationally expensive to render. I notice a 2nd thread had a similar call stack and was waiting on a mutex (Mutual Exclusion) lock, which is used to coordinate access of multiple threads to a shared object. It's possible there's a synchronization problem or race condition between multiple threads.

Before filing a bug, we need to do more work to find the problem boundaries, e.g, at what version did it appear, etc. However because of all the work you did to narrow this down, that will make this easier. 

On my i7 iMac it took about 2 minutes to crash during a ProRes 422 export, so it's not instant.  See attached TXT format crash dump from my i7 iMac 27.

One more data point here. Successful export to ProRes, no hang on quit.

2019 i9 iMac / 96GB RAM / Sonoma / FCP 10.6.10
Rendered to a 2-disk SSD RAID0 in a TB2 Sonnet Echo 15

Render took about 25 minutes, low CPU usage in Activity Monitor.

The crash during export happens on 10.6.5 on my 2017 iMac 27. I then I exported a ver. 1.9 XML from 10.6.5 (required for 10.6.2), but could not get the XML to load on 10.6.2 on that machine -- the XML load just hung. 

I got the 10.6.2 version to run on M1 Ultra, and (similar to 10.6.5 on that machine) it exported to ProRes 422, but extremely slowly. It takes about 15 min to export that little 3 min. timeline containing nothing but that "Drifting" generator. After the export, FCP was somehow deranged. It hung during shutdown and I had to kill the process.

It's at least partially related to the shape control of that generator. If set to the "bubble" shape, it does not happen. If set to the "sparks" shape, it happens.

Summary of tests thus far:

FCP 10.6.5 and 10.6.10 on 2017 i7 iMac 27 running Ventura 13.6 will crash when exporting a 3 min timeline containing only the "Drifting" generator set to the "spark" shape. The crash happens whether exporting H264 or ProRes 422. It may take several minutes to finally crash. 

FCP 10.6.2, 10.6.5 and 10.6.9 on M1 Ultra running Ventura 13.6 will successfully export that timeline, but it's abnormally slow - about 15 min for the 3 min. timeline. Afterward FCP is un an unstable condition and hangs on shutdown. A spindump taken in that hung state shows stack traces similar to the crash scenario on Intel.

The CPU/GPU behavior is different between Intel and Apple Silicon. On Intel the export is largely CPU-bound, with little GPU activity. On M1 Ultra, it's the opposite -- export is mostly GPU bound with little CPU. Relationship to the underlying problem is unknown.

Tomorrow I'll take an XCode Instruments trace of the slow export on M1 Ultra.

dmetz wrote:

One more data point here. Successful export to ProRes, no hang on quit.

2019 i9 iMac / 96GB RAM / Sonoma / FCP 10.6.10
Rendered to a 2-disk SSD RAID0 in a TB2 Sonnet Echo 15

Render took about 25 minutes, low CPU usage in Activity Monitor.

Thanks for doing that. I don't understand the varied behavior. I'll run it on several other machines tomorrow.

If your CPU activity was low, check the GPU activity. There might be certain GPUs that are leveraged by this code path. What are the GPU specs on your machine? That model had many GPU config options.

dmetz wrote:

... Successful export to ProRes, no hang on quit.

2019 i9 iMac / 96GB RAM / Sonoma / FCP 10.6.10
Rendered to a 2-disk SSD RAID0 in a TB2 Sonnet Echo 15....

I have a similar 2019 i9 MacBook Pro 16, running the same versions. It also does not crash during the ProRes export nor hang on quit. My 2017 i7 iMac 27 does crash (as does the OP's quad-core i5 iMac 27).

I've also tested the following Apple Silicon machines: M1 Ultra Mac Studio, M1 Max MacBook Pro 16, M2 Pro Mac Mini (all top spec, all running FCP 10.6.10 on either Ventura 13.6 or Sonoma 14.0).

The Apple Silicon machines don't crash during export but FCP cannot be shut down without a perpetual hang. A spindump of the hung process indicates it's the same underlying problem as the crash.

It is probably a thread synchronization problem caused by the Ozone framework (the Motion runtime engine) improperly handling a mutex lock on a shared resource. When multiple threads handle synchronization improperly, it can create race conditions or timing windows that behave differently on different machines, especially machines with varying numbers of CPU cores.

I took an XCode Instruments trace on an Apple Silicon machine that indicates the problem threads are using manual threading via _pthread and manual synchronization via mutexes. The other threads are using Grand Central Dispatch, which can be identified by worker threads called _dispatch_etc. GCD saves the application from handling locks and manual threads. Why the Ozone framework uses such a mix, I don't know. It probably goes back to the original design.

When the crash or hang happens, one manually managed _pthread crashes and a 2nd _pthread is waiting on a Mutex lock. This suggests that the two threads are trying to coordinate access to a shared resource in a manner that is not thread safe.

Instruments trace: joema.smugmug.com/FCP-Instruments-Trace-...-Generator/n-5fF9FV/

The problem is likely not caused by the "Drifting" generator itself. That is simply an XML file in this location:
/Applications/Final Cut Pro.app/Contents/PlugIns/MediaProviders/MotionEffect.fxp/Contents/Resources/Templates.localized/Titles.localized/Build In:Out.localized/Drifting.localized/Drifting.moti

Correction: it is a .motn file, not .moti. (Thanks, DaveM). However, I think the conclusion is unchanged: the generator file itself is not the cause of this problem. 

/Applications/Final Cut Pro.app/Contents/PlugIns/MediaProviders/MotionEffect.fxp/Contents/Resources/PETemplates.localized/Generators.localized/Backgrounds.localized/Drifting.localized/Drifting.motn

You can examine that and diff various versions of Drifting.moti  Drifting.motn using BBEdit, Beyond Compare, etc. The Drifting.moti Drifting.motn file did change between 10.6.5 and 10.6.6, but that isn't the problem because the crash/hang happens before and after that change.

The Instruments trace shows that during the export, the two _pthreads are not running concurrently but they are waiting on some shared resource. They take turns, running about 41 milliseconds each. On my Apple Silicon machines the export is bottlenecked on the GPU, so maybe those threads are handing off buffers to the GPU, and maybe due to timing uncertainties they eventually make a synchronization error and crash.

I'll file a bug on this tomorrow. Thanks to everyone for all the help.

My iMac has one of the 8GB options, but I can't remember if it's the Radeon 580X or the Pro Vega 48. Will need to check when I get home later.