FCPX 10.6.6 crashes always if I open an older library which worked in 10.6.5

It's not unique to Apple Silicon or Ventura 13.4. The 10.6.5 library I have crashes when upgrading to 10.6.6 on Ventura 13.3.1(a) on both Intel and Apple Silicon.

There is a possible workaround if you export a library XML on 10.6.5. At least in my case that will load on 10.6.6. It's probably a good standard practice to do periodic XML exports of your library and essential projects, anyway, but especially right before an upgrade.

The crash log implied it might be related to something in a multicam clip associated with a gap clip. On 10.6.5 I successively deleted projects, each time shutting down FCP and duplicating the library, then trying to upgrade it on 10.6.6. I got to one project left, and there was a multicam clip on top of a gap clip in the timeline, but there was nothing visibly wrong with it. However when I deleted that one instance of the multicam on top of the gap, it quit crashing when attempting the upgrade. I did not delete the parent multicam in the browser.

For anyone facing this problem, my first suggestion is open the library on 10.6.5 then export a library XML and try to load that in a new blank library on 10.6.6. If you don't have 10.6.5 you'll need to obtain that somewhere.

If you have Time Machine or any other type of backup you can get it from there. All you need is the Final Cut Pro.app bundle. You can name one Final Cut Pro_10_6_6.app and one Final_Cut_Pro_10_6_5.app and double-click on each one in Finder to selectively launch them.

I ran the OPT+Clip>Verify & Repair Project command, but it didn't find anything on the single remaining project where the upgrade would crash. So there was nothing visually wrong in the timeline and that check did not find anything.

However I exported that project XML, loaded it in 10.6.6, exported the project XML there and "diffed" the two XMLs using Beyond Compare (both were XML version 1.10). There were a lot of changes which seems odd since it was the same project. I will study this more tomorrow.

No, I only meant that when trimming down the replication scenario prior to filing a bug, it becomes very finicky to maintain the behavior in a small, simple library and single project. On that reduced-size scenario, making very slight changes such as removing an audio volume effect will make it stop. However that does not prevent it on the full-size scenario.

In my tests, simply taking the original library, exporting a library XML on 10.6.5, creating a new blank library on 10.6.6, then loading that library XML seemed to prevent the problem. However, I only have one library that causes it, so this might not represent the full range of conditions.

It appears the underlying problem is a newly-added method (aka function) in 10.6.6 is performing an Objective-C technique called "fast enumeration" during the library update. When that is performed, no elements in the array being enumerated can change, otherwise it will cause an exception. It appears only the main thread was running, but there are various possible errors whereby a thread performing fast enumeration can accidentally change its own array during that interval.

From an end-user standpoint, exporting a library XML on 10.6.5 and then importing that XML on 10.6.6 to a new blank library seems to avoid the problem, maybe because it bypasses the specific library update code.

However, if someone tries that and it doesn't work, please post that here.

Here is another thing that you may try. It may work, but of course there are no guarantees.

Quit FCP.

In the Finder, control-click on the library and choose Show Package Contents.

Drag the CurrenVersion.flexolibrary from inside the bundle, and put it temporarily somewhere else (or in the trash).

Try opening the library. It may tell you that it needs to be updated, and maybe this time it will work.

Please post an EtreCheck report https://etrecheck.com giving the application Full Disk Access in Privacy & Security System Settings. Copy the report and use the Add Text button to paste the result into reply box. 

This is apparently caused by or related to a new method (ie function) added in 10.6.6 called [FFMediaEventDocument update_repairMulticamClippedRangesAndGap]. I don't know if there is a bug in the new function or if it's finding a problem which was not checked in prior versions.

While it seems to involve a multicam clip and a gap clip (both showing no apparent problem), attempting to trim down the scenario beyond a certain point becomes unpredictable. Doing seemingly unrelated minor things like removing a volume audio attribute can make it stop happening.

Trash your preferences whenever the application crashes. Your system drive is essentially full. 25.36 GB. You need a minimum of 15% free space and really should have 20%.

My first reaction is that the library bundle is way, way too big. Storing in the library is fine for moderate sized or smaller productions, but this is far beyond that.

Are you sure the library has been updated in 6.6? Or did it crash before updating? Do you have a copy of 10.6.5, maybe on a Time Machine drive? If so use that to try to open a backup of data library from Final Cut Backups?

The previously-mentioned workaround was export a library XML on FCP 10.6.5, close all libraries, save your FCP 10.6.5 Final Cut Pro.app file by zipping, upgrade to 10.6.6 (which will not upgrade any non-loaded libraries), launch FCP 10.6.6, create a blank library and load the library XML you exported from FCP 10.6.5.

You can have multiple versions of FCP on your machine at the same time, but you can only run one at a time. I usually name mine something like "Final Cut Pro_10_6_5.app", etc. You just double-click on the one to launch in your /Applications folder. It is a good practice to always save and ZIP the current version of FCP before upgrading, in case you need to go back.

This was for the known behavior of an immediate crash when updating an older library to 10.6.6. There was no known behavior where the upgrade would work but then it would later crash. That could be a different problem.

If there's any doubt of the library's version, you can inspect the version of an FCP library using Finder. If you right-click on the library, pick "Show package contents", then select CurrentVersion.plist, and press the space bar to launch "Quick Look", that will show the Catalog Version (IOW the FCP version last used on that library).

I had this happen today when trying to open a 10.6.5 library using 10.6.6. This was on an M1 Ultra Mac Studio, 128GB RAM, 64-core GPU, 8TB SSD, 6TB free. Library was on the internal drive and media was on a 16TB Thunderbay 4 Mini with all SSD storage, 3.6 TB free.

I switched to 10.6.5 and it opened OK. Stack trace attached. I'll try to reproduce it on a library without any attached media and if so I'll file a bug. The class/method call FFMediaEventDocument update_repairMulticamClippedRangesAndGap might be newer source code since I don't see any Google references to it. I examined all the multicams in the library and they look OK.

Did you trash preferences?

Do you have a backup of that library from before it was updated?

It seems to me that - probably due to the system disk being full at the time - the update did not go through successfully, resulting in some corruption in the library.

You may have more success if you try it now - provided that there is a backup.