TOPIC:

Final Cut X is constantly crashing or blocked thinking since Ventura updateHello.
I'm user of FCPX since ever. Never had issues, always work great. But since I update macosx to Ventura, FCPX is constantly crashing or blocked processing.... I have Macstudio m1 ultra with 64gb ram, and working videos 4k, that my MacBook Pro intel runs softly. So what's the problem here? Because I only noticed this since Ventura macs update. Every time I try to color grading, even with color correct of FCPX, it crashes...I use also Film nitrate and Color finale plugins.
Thank you very much,Bruno Santana

Bruno, part of your issue may have to do with Security and Privacy settings in your System Settings. macOS Ventura often requires users to re-approve various parts of one's system. You may need to "add" any external drives, "full disk access" for FCP and other applications, etc.

Pitcho7 wrote:

...since I update macosx to Ventura, FCPX is constantly crashing or blocked processing.... I have Macstudio m1 ultra with 64gb ram, and working videos 4k, that my MacBook Pro intel runs softly....Every time I try to color grading, even with color correct of FCPX, it crashes...I use also Film nitrate and Color finale plugins...

I'm running FCP 10.6.5 and Ventura 13.1 on a top-spec M1 Ultra Mac Studio. In general it seems reliable when grading 4k/23.98 Sony XAVC-I and 8k/23.98 RED RAW. However I don't use Film Nitrate or Color Finale.

It is unfortunately common for plugins to make FCP crash after updating MacOS or a FCP version. That is normally fixed by the plugin developer updating their software. Can you verify you are on the latest versions of those plugins? If you already are on the latest versions, try resetting FCP preferences (item 11 on this page): support.apple.com/en-us/HT203477

If it still hangs or crashes, turn off background rendering, in FCP preferences, delete all render files by selecting the library in the left sidebar, then File>Delete Generated Library Files>Delete Render Files>All.

DaveM wrote:

Bruno, part of your issue may have to do with Security and Privacy settings in your System Settings. macOS Ventura often requires users to re-approve various parts of one's system. You may need to "add" any external drives, "full disk access" for FCP and other applications, etc.

Thanks for this suggestion. I applied this now, I hope Final Cut will work better now.

More of this, I was working with less improvvise crash, with background rendering disabled.

macOS 13.2 introduced a bug that will crash FCP if you have a lot of items (>600) in a single event. I got word that there are crashes in lots of different apps in 13.2 due to complexity, number of items in the browser/finder - this affects other apps as well, not just FCP. Current workaround is to reduce the number of items in your event or downgrading the OS to 13.1.

sampl_e wrote:

macOS 13.2 introduced a bug that will crash FCP if you have a lot of items (>600) in a single event.

I'm glad I saw this before I "updated". Ventura (all flavors) already has issues opening folders with lots of stuff in them. More so than any other version of Mac OS ever. Open a folder with lots of stuff and you'll see the spinning fan blades as it sorts things out. Not sure what they did or why they did it, but it's not cool. Sounds like 13.2 makes it even worse. I have a feeling it's probably not gonna get any better. Everyone should stay on MacOS 12.x for now until Apple proves my comments wrong/obsolete (which I sincerely hope they do... fast!)

sampl_e wrote:

macOS 13.2 introduced a bug that will crash FCP if you have a lot of items (>600) in a single event. I got word that there are crashes in lots of different apps in 13.2 due to complexity, number of items in the browser/finder - this affects other apps as well, not just FCP. Current workaround is to reduce the number of items in your event or downgrading the OS to 13.1.

I am examining this. There is no question if you have a lot (e.g, 5,000) clips in an event, certain actions such as filtering on a clip name becomes very slow. The question is did that suddenly start with MacOS 13.2.

Yes, it definitely started with 13.2, because downgrading to 13.1 solves it. I’m aware that filtering becomes slow, but this bug will crash the app instantly. Dragging a file from finder into the browser in a large event will crash the app immediately. I was able to replicate this behavior on different (Apple silicon) machines.

The root cause has apparently been in place for a couple of years, why it’s become a problem with the update is being investigated.

Very bad news. I'm working on my honeymoon, so I have a lot of clips and photos, is impossible to reduce my objects on my daily events.

And I think is not rational to downgrade the Operating System... I'm really angry for this issues....

I'm trying to create a new library, with only an event of the original library, without media copied, only linked.... hope works.

Anyone who is having the FCP crash problem on Ventura, please save your crash files as plain .txt. You can copy/paste to TextEdit with menu Format>Make Plain Text.

If you had a recent crash, the FCP crash logs should be in ~/Library/Logs/DiagnosticReports
You can go there in Finder by doing menu Go>Go to Folder then copy/paste of the above location to there.

On Ventura the crash report should be an .ips file which is readable by Quick Look, TextEdit, etc.

If you can please drop those in this write-only DropBox folder. Rename them by your fcp_co screen name. I will inspect them for any clues. This is just for this one problem; I can't provide private follow-up or look at everyone's crash logs forever www.dropbox.com/request/w5Tb4uisD75ou49ilWYt

Regarding a possible workaround for an FCP crash during drag/drop import from Finder, try using the FCP import dialog. Even if it works, that is just a stopgap; there are definitely some real problems here.

Dropped you a file in the dropbox. Even the import dialogue will crash FCP. Anything you do to a large event will crash it, folks at the FCP team told me to reduce the number of items on an earlier OS or downgrade it.

sampl_e wrote:

Dropped you a file in the dropbox. Even the import dialogue will crash FCP. Anything you do to a large event will crash it, folks at the FCP team told me to reduce the number of items on an earlier OS or downgrade it.

Your crash dump is quite complex; I haven't seen anything like that before. On the thread 0 application-specific backtrace, with a single exception there are no FCP frameworks or classes listed. On frame 128 it references LunaKit which is an FCP UI framework. The rest of the call stack from frame 127 up to the crash frame 0 are all MacOS frameworks. There are apparently recursive calls in some NS (that means NextStep) methods. Those are probably signs of an anomaly.

In the concise thread 0 stack there is a call to NS_setFlushesWithDisplayLink which may be associated with using multiple monitors. We had a previous problem reported by well-known editor Thomas Grove Carter which was related to multiple monitors. In his case disconnecting those temporarily was a workaround. I had the same dual monitor config as him but I could never reproduce it.

If you have multiple monitors on the problem machine, as a troubleshooting step can you try disconnecting that and see if the problem can be reproduced? If so please send me that crash dump.

In the Thomas Grove Carter case, he eventually determined it was a combination of his dual monitors and the MacOS system setting "automatically adjust brightness". We think that was fixed in 10.6.5 but we aren't sure. Can you check if that is disabled on your machine (as an editor you'd normally want that).

If that doesn't help, I notice in your crash log you have considerable external devices connected to your M1 Ultra. Can you disconnect everything possible and try to reproduce the problem? I also have an M1 Ultra with multiple Thunderbolt arrays and so far haven't seen your symptoms, although I have one OWC Thunderbay 4 Mini with 4 x 4TB SSDs that will sometimes cause a kernel panic if I reboot with it connected.

If you are using SoftRAID please provide the specifics -- what version, what configuration on your arrays, etc. If any of your arrays have kernel extensions, let us know. If you could please run this terminal command and post the results here, it may find some non-Apple kernel extensions:

kmutil inspect | grep -v com.apple

Even if the above steps indicate a possible configuration issue, there is no question there are multiple problems in play. I've seen some of those myself, and will post more information soon.

For the others seeing FCP crash on Ventura when doing drag/drop import to a large even, try using the FCP import dialog as a temporary workaround. Please report whether that makes any difference.

For those using RED media make sure you are on the latest version of the Apple RED workflow, version 20, dated 9-26-22: www.red.com/download/red-apple-workflow-installer

If you have Canon or other workflow/codec packages, make sure they are updated.

On Ventura the latest version of Apple Pro video formats is 2.2.4. The version can be examined in System Settings>General>About>System Report>Software>Installations, then on the right pane scroll down to "Pro Video Formats". It can be updated in System Settings>General>Software Update. If available it will automatically appear after a short delay.

Thanks for your insight. Multi monitor setup can be ruled out as this also happens without any external displays attached, even without any external hard drives. The ones I’ve been using are from OWC but no SoftRaids. The ‚adjust brightness…‘ setting has indeed been fixed, but I keep it off anyways, so again that can be ruled out.

What I’m hearing is that those issues are not only happening with FCP, but system wide. It seems related to the complexity or number of elements in the browser - that complexity limitation has apparently been for a couple of years, so it’s not clear why it’s become an issue now. That’s all I’ve been hearing so far.

sampl_e wrote:

Thanks for your insight. Multi monitor setup can be ruled out as this also happens without any external displays attached, even without any external hard drives...

If you mean you've seen apparently Ventura-related FCP crashes on other single-monitor Macs, unless the stack traces look very similar it could be something different. There are various causes of FCP crashes. If you mean it's happened on your M1 Ultra Mac Studio with only a single monitor and no other outboard video hardware, let me know. If there is any uncertainty just send me the other crash logs.

sampl_e wrote:

...What I’m hearing is that those issues are not only happening with FCP, but system wide. It seems related to the complexity or number of elements in the browser - that complexity limitation has apparently been for a couple of years, so it’s not clear why it’s become an issue now...

Could you please elaborate on "not only happening with FCP".

I believe you're correct about the FCP browser/timeline complexity issue. It was present two years ago in some form. It definitely seems worse on current versions. It involves aspects of the Event Browser and timeline, which use separate SQLite databases but share much of the same framework code.

For example I pulled from archives a complex timeline I edited about three years ago on a 2017 iMac 27. It was sluggish then but doable. On my M1 Ultra (excluding the Long GOP video acceleration) it seemed the same or worse -- and that's on a Mac several times faster in single-core, multi-core and GPU.

A clear example is the extreme performance problem in filter by filename in the browser if the event has a few thousand clips. In 2017 I edited a complex timeline on a 2017 iMac 27 which had 5,000 clips in one event. Filename filtering was a bit sluggish but usable. Today filename filtering cannot be used reliably on a 5,000 clip event on my M1 Ultra. If you start typing the filename with the beginning letters and it matches lots of rows FCP essentially hangs for 30 seconds or more. Many users would think it crashed. By contrast I imported 13,000 clips into Resolve Studio 18.2 and filename filtering worked fine. I put all 13,000 clips on a single timeline using the "source tape" feature and it was a bit sluggish but OK.

On current versions of FCP you can't drag/drop import lots of files on the current version. When the file group reaches the event, it takes FCP 30 sec or more to respond to Finder and display an "in place" arrow. You can't even tell what event you're importing to. Admittedly it works OK on the low end; I'm talking about a lot of files. But it used to work much better -- even on slower hardware.

In these cases if I take an XCode Instruments "Animation Hitch" trace, it shows severe problems. Apple's speakers at recent WWDCs say that should never, ever happen.

There is a major FCP scalability issue which ironically has gotten worse the past two years or so, despite faster hardware. For those not working with large libraries and highly complex timelines it may seem OK, but there is an underlying problem. Thank you sampl_e and others for reporting this.

If anyone thinks "that doesn't affect me, I've never seen it", wait until you get a few thousand clips in an event and try to filter by filename.

sampl_e wrote:

... It seems related to the complexity or number of elements in the browser...

I just had it crash with a very similar stack trace to one of yours. The scenario was incredibly simple: I had one event in a new test library which contained about 9,700 short (2-3 min) clips from an HEVC security camera. I created a default project, selected one clip with the browser in list view, pressed the E key to add to the timeline and it crashed. I then reproduced it but I had to add 2 clips to the timeline before it crashed.

This is really good -- it gives me a reliable starting point for further study, with a goal to narrowing it down to a scenario I can file with Apple. I will also test on other machines and versions. This library has lots of clips but they are small. They are imported "in place" and the total dataset is only about 50 GB.

The crash is similar to yours where the last several frames in thread 0 all say "-[NSView _informContainerThatSubviewsNeedUpdateConstraints]"

sampl_e wrote:

macOS 13.2 introduced a bug that will crash FCP if you have a lot of items (>600) in a single event...Current workaround is to reduce the number of items in your event or downgrading the OS to 13.1.

I confirm this is 100% correct. It is a severe problem. Known parameters: Happens reliably with only 500 clips in one event of a new library. Codec, resolution, whether files are imported "in place" or "copy to library" -- all do not seem to matter. Reproduced on M1 Ultra Mac Studio and M2 Pro Mac Mini. Happens with FCP 10.6.2 through 10.6.5. Does not happen with those FCP versions on Monterey 10.6.3, either Apple Silicon or Intel.

I don't have a Ventura 13.1 machine so I can't verify the crash problem started with 13.2.

Procedure to reproduce it:
- Create a new library
- Import 500 clips to an event
- Create a new default project
- Start adding clips to the event one at a time. It will usually crash by the 2nd clip.

The crashing stack trace shows repeated calls to -[NSView _informContainerThatSubviewsNeedUpdateConstraints]

The crash log will either be written to the screen or can be seen by running the Console app and clicking on Crash Reports in the left sidebar. They are in ~/Library/Log/DiagnosticReports.

I will discuss this with Apple tomorrow.

Can confirm that the above does NOT happen in Ventura 13.1. Seems to be limited to 13.2.

Does how you import matter? Is it the single import to a large event the issue?

I think the issue is number of clips in a single event. If I put 500 clips in one event, then start adding clips to a new project, the crash happens every time.

If instead I split those 500 clips between two events, 250 in each, it does not happen. I've repeated it about 30 times today using various parameters. I don't yet know the low limit but for me it happens on multiple Ventura 13.2 machines using 500 clips in an event, the moment I start adding clips to a new empty project.

On the library with 250 clips in each event, after I added a few clips to a project it did not crash. Then I grabbed the 250 clips in one event and drag/dropped them to the other event -- it immediately crashed.