Intel MacBook Pro - Kernel Panics in FCP Under Heavy Load

[Unboundclassic]

Apple Feedback Assistant ID: MISSING

I have an Intel MacBook and have had an issue for a long time (and though many versions of FCP now, including 10.8 ) with Kernel panics during (usually) heavy loads in FCP. Certian plugins (like OSM iPhone) almost guarantee it happening. The computer locks up for a minute+ and then crashes. The screen first, then audio near the end, then mouse, then crash. Same every time.

I also run very heavy processes in DaVinci Resolve and Premiere and I do not get the same Kernel panic's there. At least not as constant or repeatable. Very rarely do I get the same issue in any other program. Which says to me there's something about how FCP or FXPlug is coded that my computer does not like. It may force me into other NLEs until I can manage to upgrade my Mac. Unless the Apple team can tweak the code to eliminate this issue.

I can provide a crash report if there's a way to send it. It won't let me attach it here.

[latenitefilms]

@Unboundclassic - FYI - You originally posted this in the CommandPost repo - I've moved this across to FCP Cafe.

You should be able to upload a ZIP file with any crash logs.

You can read about where to find your crash logs here.

To be perfectly honest, I think Apple has kinda given up on Intel support, and non-Apple Silicon GPUs, so even if you work out a way to reproduce the bug, I think the chances of getting it fixed are pretty unlikely.

[joema4]

A user-mode application cannot be responsible for a MacOS kernel panic, with the sole exception of that app using a kernel extension (which are strongly depricated on Intel MacOS and prohibited on Apple Silicon). The app in question in this case is FCP which does not use kernel extensions.

The hardware-enforced isolation between user mode and kernel mode is absolute. If a software code error in a user-mode app (such as FCP) could cause a kernel panic, then nefarious actors could leverage that to crash MacOS systems worldwide.

It can appear an app is responsible for a kernel panic, just like it appears a certain heavy truck caused a bridge to collapse, when another truck did not. However that bridge had unseen damaged and the truck was well within the weight limit. People might say "it never collapsed before until that specific truck came along". But the actual cause was a deficiency in the bridge. That problem cannot be fixed by using lighter-weight trucks.

Likewise with MacOS kernel panic, the problem cannot be fixed by changing something in an app. It must be addressed at a system level, which means things like OS, kernel extensions, hardware, disk space, etc.

[Unboundclassic]

I've attached one of the system crash logs.
WindowServer-2024-06-29-191005.ips.zip

[Unboundclassic]

@Unboundclassic - FYI - You originally posted this in the CommandPost repo - I've moved this across to FCP Cafe.

You should be able to upload a ZIP file with any crash logs.

You can read about where to find your crash logs here.

To be perfectly honest, I think Apple has kinda given up on Intel support, and non-Apple Silicon GPUs, so even if you work out a way to reproduce the bug, I think the chances of getting it fixed are pretty unlikely.

Ya I figured but I also thought I might as well try as I have no way to upgrade at the moment $$$.

[Unboundclassic]

A user-mode application cannot be responsible for a MacOS kernel panic, with the sole exception of that app using a kernel extension (which are strongly depricated on Intel MacOS and prohibited on Apple Silicon). The app in question in this case is FCP which does not use kernel extensions.

The hardware-enforced isolation between user mode and kernel mode is absolute. If a software code error in a user-mode app (such as FCP) could cause a kernel panic, then nefarious actors could leverage that to crash MacOS systems worldwide.

It can appear an app is responsible for a kernel panic, just like it appears a certain heavy truck caused a bridge to collapse, when another truck did not. However that bridge had unseen damaged and the truck was well within the weight limit. People might say "it never collapsed before until that specific truck came along". But the actual cause was a deficiency in the bridge. That problem cannot be fixed by using lighter-weight trucks.

Likewise with MacOS kernel panic, the problem cannot be fixed by changing something in an app. It must be addressed at a system level, which means things like OS, kernel extensions, hardware, disk space, etc.

Interesting... BUT that doesn't explain what's happening here. I have enough experience with this happening consistently over a LONG period of time (at least a year or more) and 99.8% of the time with FCP in active use. And always with the same behavior while freezing. It's not just some recent observation. The kernel panics may be a symptom of something underlying that is damaged/issues in the computer. Sure, I get that. But why is it just FCP that is working when it happens? There's no way it's just coincidence. It's way, way, too consistent. It's consistent enough I could probably reproduce the issue in less than 30 mins. It happened 3-4 times the day I posted this over four hours or so. But I haven't been able to see that behavior in any other program. I've run all sorts of projects in Premiere and Resolve, for example, and no issues like this. Same with After Effect and even Motion I believe. The only other time I recall it happening for sure is once in Affinity Photo or Designer last year some time. If it's not supposed to be possible for FCP to trigger a kernel panic... why is it happening?

[latenitefilms]

Do you have any of the Kernel Crash logs?

Does Final Cut Pro crash when the computer kernel panic's?

The WindowServer crash log I think is irrelevant, and not really an issue.

My GUESS is that it's probably something to do with the GPU failing.

What kind of footage are you working with?

[Unboundclassic]

OK I think I got the right log this time.

Ya GPU would make sense.

The sequence is:

1. The entire system/FCP UI freezes/is unresponsive, but the mouse can still move. FCP doesn't crash first if that's what you're asking.
2. After around a minute or so any audio playing stops. Like from Apple Music.
3. Around or at the same time the mouse also freezes.
4. After 10-20 more seconds the screen goes black and the fans spin up to full speed briefly.
5. The computer auto-restarts and goes to the kernel panic screen (for lack of a better name).
6. After the restart it asks if I'd like to submit a crash report.

Rinse and repeat.

I've seen it crash with stock video, ProRes 4444 graphics, live graphics, .mp4, .mp5, ProRes 422, and just live graphic plugins. In particular the OSM iPhone and OSM iPad plugins are to the point where it probably crashes more often than not when trying to export a project that I use those plugins in. But the project the other day that I mentioned above was 100% ProRes 422 camera footage and some music. No plugins.

Kernel_2024-06-29-191014_Bradens-MacBook-Pro.gpuRestart.zip

[latenitefilms]

Have you tried doing Apple Diagnostics (formerly known as Apple Hardware Test)?

See: https://support.apple.com/en-us/102550

[joema4]

Apple Diagnostics is a good idea because it's easy to run. If it shows an error there is usually a problem. However an error-free pass does not mean a clean "bill of health."

The Genius Bar at Apple stores have access to overnight and multi-day stress tests that will find elusive problems that don't show up on Apple Diagnostics. I formerly had a machine that passed 20 runs of Apple Diagnostics but overnight tests by the Genius Bar found a GPU problem.

[Unboundclassic]

No luck on the basic hardware test.

[Unboundclassic]

I also updated to Sonoma 14.5 (from Ventura) just now to see if that does anything. All previous OS updates haven't seemed to make a difference though. I'll see how it behaves today.

[Unboundclassic]

I was doing pretty well since the Sonoma update, but then I had multiple crashes again yesterday once the FCP project got heavy.

[joema4]

As explained above, the CPU hardware and Address Translation Unit ensure absolute isolation between a non-privileged user-mode app like FCP and the system. FCP can no more crash the system or GPU through misbehavior than a human prisoner could escape a welded steel cube. There is no source code in FCP which could be changed to avoid this.

The problem mainly (but not solely) occurs when running FCP and not Resolve or Premiere. This is due to the complex multi-dimensional interaction between the application and the system. This interaction involves timing, threads, DMA transfers, memory, graphics, compute, and contention for GPU channels. If it could be represented, it would require a complex data visualization using a 3D glyph plot.
(https://en.wikipedia.org/wiki/Glyph_%28data_visualization%29)

In short, each seemingly similar app is interacting with the underlying system in a unique and subtle manner. If there is a deficiency in the infrastructure below the app layer, it is possible only one app could encounter that.

If by "crashes," you mean an OS failure such as a kernel panic, system hang, spontaneous reboot or GPU restart, an application-layer issue is not responsible for that, and no application software change can fix it. If FCP is crashing, a system level instability or incipient hardware failure can cause that, or it could be an FCP bug. But this problem history strongly implies it is a system-layer problem: hardware, operating system, etc.

If I worked for Apple, I'd get someone in MacOS support to contact you. But alas I'm just an end user like you. In my spare time I try to help people with FCP problems, but I don't have the knowledge, time or information to debug a Mac hardware or OS problem.

I suggest you contact Apple MacOS support. If you have access to an Apple Store, make an appointment with the Genius Bar and take your machine in for more extensive diagnostics. Request they run overnight "bench diagnostics". Explain to them the problem history and the kernel panics. The sooner you pursue that, the sooner it will be fixed.