-
Pro Apps Crash Too Often
Why is that that when you are really pushing an app hard, the ProApps software like Final Cut Pro X crashes more often than any other post software? And worse than just crashing, it totally messes up the machine so that you can’t simply force quit, but have to do a hard restart.
It’s not a poof and the app’s gone. It’s the beachball of death. That’s the dark side of having the app so tightly integrated into the OS. It’s gotten worse than it was in older versions.
Say what you will about Premiere Pro, but I just never have the same sort of bad experience.
– Oliver
Oliver Peters – oliverpeters.com
-
22 Replies
-
[Oliver Peters] “Say what you will about Premiere Pro, but I just never have the same sort of bad experience.
“and of course you know people like me will then post that we have almost zero problems with FCPX reliability, even when pushing hard and the unreliability of PPro seems to reported a lot.
As with any system have you tried narrowing down exactly what’s causing it to crash, what exactly do you mean by “pushing hard”? have you spoken to Apple about it? Have you done re-installs etc etc.
Also your first statement reads like it’s a broad problem
[Oliver Peters] “Why is that that when you are really pushing an app hard, the ProApps software like Final Cut Pro X crashes more often than any other post software? “
Perhaps you should have said “When I’M really pushing an app hard”?
\”Traditional NLEs have timelines. FCPX has storylines\” W.Soyka
-
[Oliver Peters] “Why is that that when you are really pushing an app hard, the ProApps software like Final Cut Pro X crashes more often than any other post software? And worse than just crashing, it totally messes up the machine so that you can’t simply force quit, but have to do a hard restart..”
I completely agree. When I push FCPX really hard with a big complex timeline, I sometimes have four crashes per day. I have three iMacs and a 10-core iMac Pro, it happens on all of them. It’s not a new issue, it’s always been like that. It’s not failure to trash prefs or insufficient disk space or an oddball plugin. My current timeline has one 3rd party plugin on one clip and it’s disabled.
In my case the most frequent application-layer crashes happen when using multiple 10.4 color correction effects. The call stack (for this particular case) is below. While this seems new to 10.4, it’s just one current manifestation. FCPX has been like this since I first used it in 10.0.9.
But as you said there are also app crashes which either destabilize macOS or something in macOS has become deranged and causes the FCPX crash. In those cases a clean shutdown is impossible, even using terminal. Then I have to run First Aid on all my drives which takes a while. Some of this may not be the fault of FCPX, it could be macOS issues.
I used Premiere on Windows a lot on CS5 and CS6, and it also crashed a lot when pushed hard but Windows almost never hung or crashed.
This is where I disagree with some commonly-advocated requests for new FCPX features. While it would be nice to have color coded video lanes or a scrolling timeline, what I want is consistent, reliable stability and performance under high load and a variety of codecs.
Instead of glitzy UI features, I would rather they fix relink, make proxy management work better, or add a library database verifier. They need to rearchitect the plugin system so one CPU-intensive plugin doesn’t hog the UI for the entire app. If they are going to address UI feature issues, why not fix things which are confusing to users, such as the inconsistent requirement to open and blade multicams for some effects but not others.
I appreciate what Apple has accomplished with FCPX. The product managers are apparently trying to focus on performance and stability and they are being cautious about adding features — that is good. But more work is needed in this area.
Common FCPX 10.4 crash during color correction (2017 top-spec iMac 27, macOS 10.13.4, 4k H264 4:2:0 8-bit media):
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff73a5cb6e __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff73c27080 pthread_kill + 333
2 libsystem_c.dylib 0x00007fff739b81ae abort + 127
3 libGPUSupportMercury.dylib 0x00007fff645b40f1 gpusGenerateCrashLog + 168
4 com.apple.AMDRadeonX4000GLDriver 0x0000000106fbaf2b gpusKillClientExt + 9
5 libGPUSupportMercury.dylib 0x00007fff645b54d6 gpusSubmitDataBuffers + 184
6 com.apple.AMDRadeonX4000GLDriver 0x0000000106f92332 glrATI_Hwl_SubmitPacketsWithToken + 154
7 com.apple.QuartzCore 0x00007fff56985a2c CAOpenGLLayerDraw(CAOpenGLLayer*, double, CVTimeStamp const*, unsigned int) + 1985
8 com.apple.QuartzCore 0x00007fff56985073 -[CAOpenGLLayer _display] + 565
9 com.apple.QuartzCore 0x00007fff56925973 CA::Layer::display_if_needed(CA::Transaction*) + 633
10 com.apple.QuartzCore 0x00007fff56925431 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 35
11 com.apple.QuartzCore 0x00007fff56924434 CA::Context::commit_transaction(CA::Transaction*) + 326
12 com.apple.QuartzCore 0x00007fff56923fe1 CA::Transaction::commit() + 487
13 com.apple.AppKit 0x00007fff49488a72 __65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke + 283
14 com.apple.CoreFoundation 0x00007fff4b614467 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
15 com.apple.CoreFoundation 0x00007fff4b61438f __CFRunLoopDoObservers + 527
16 com.apple.CoreFoundation 0x00007fff4b5f6908 __CFRunLoopRun + 1240
17 com.apple.CoreFoundation 0x00007fff4b5f61a3 CFRunLoopRunSpecific + 483
18 com.apple.HIToolbox 0x00007fff4a8ded96 RunCurrentEventLoopInMode + 286
19 com.apple.HIToolbox 0x00007fff4a8dea0f ReceiveNextEventCommon + 366
20 com.apple.HIToolbox 0x00007fff4a8de884 _BlockUntilNextEventMatchingListInModeWithFilter + 64
21 com.apple.AppKit 0x00007fff48b91a73 _DPSNextEvent + 2085
22 com.apple.AppKit 0x00007fff49327e34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044
23 com.apple.AppKit 0x00007fff48b86885 -[NSApplication run] + 764
24 com.apple.LunaKit 0x0000000103298e2d LKApplicationMain + 365
25 com.apple.FinalCut 0x0000000100ae3c35 main + 533
26 libdyld.dylib 0x00007fff7390c015 start + 1 -
[Steve Connor] “and of course you know people like me will then post that we have almost zero problems with FCPX reliability, even when pushing hard and the unreliability of PPro seems to reported a lot.”
I completely understand. My experience with Premiere Pro is the opposite, of course. And the same with the other editors I work along side and in other facilities around town, for the most part.
[Steve Connor] “Perhaps you should have said “When I’M really pushing an app hard”?”
My experiences tend to be worse with FCPX on networked machines. Although, it’s still touchy at times even with local storage. Naturally my post is a rant and I have had good experiences with X, too. Although lately, every time I consider more use of X over other tools, it disappoints for one reason or the other.
These crashes seem to be tied to the graphics subsystem. For example, today, the lock-up actually caused corruption of the GPU (I believe). I literally have a stain on the right edge of my Apple display after restart, caused by the crash. It will go away after a real power down and back up. That’s one example of how deeply X’s hooks are into the system in ways that other software doesn’t have.
– Oliver
Oliver Peters – oliverpeters.com
-
[Joe Marler] “In my case the most frequent application-layer crashes happen when using multiple 10.4 color correction effects. The call stack (for this particular case) is below. While this seems new to 10.4, it’s just one current manifestation. FCPX has been like this since I first used it in 10.0.9.”
See my comment to Steve. I really think how FCPX addresses the graphics subset of either the OS or the hardware is the culprit. The good side is skimming and other things people love. The bad side is something like these experiences.
FWIW – my best FCPX experiences are with the various MacBook Pros. Less so on any of the Mac Pros. I’m not sure on the iMac/iMacPros, as I have less experience running X on those models.
– Oliver
Oliver Peters – oliverpeters.com
-
I get consistent crashes when importing a PSD file saved on the desktop which seems to be a common issue. Moving said file or saving it elsewhere solves the issue. Not sure why this is.
-
When you say “pushing the software”, exactly what do you mean? Can you send a screen grab? I rarely have crashes with X on any of the three systems I work on, but I make a concerted efforts, no matter what software or project, to keep a clean and efficient a timeline as I can.
Scott Witthaus
Senior Editor/Visual Storyteller
https://vimeo.com/channels/1322525
Managing Partner, Low Country Creative LLC
Professor, VCU Brandcenter -
[Scott Witthaus] “When you say “pushing the software”, exactly what do you mean? Can you send a screen grab? I rarely have crashes with X on any of the three systems I work on, but I make a concerted efforts, no matter what software or project, to keep a clean and efficient a timeline as I can.”
I can’t post the timeline, but I can give some numbers. It’s 22 min long, all 4K H264, proxies built (but crashes happen whether proxies are used or not). Clips in timeline = 473, about 1/2 of them multicam, only three audio lanes: music, dialog, nat sound. Only one 3rd party effect which is currently disabled. The timeline isn’t that thick and mainly has a primary storyline with one or two layers of connected clips.
It was originally built from a very large library of 8,500 clips, 20 terabytes, 220 hr of H264 4k. It was extracted to a separate managed library of about 1.5 TB by copying the project. That runs on a Thunderbolt SSD array. So the current library size isn’t that big.
In general the instability seems loosely related to number of edit steps. IOW the assembly edit of the same material was fairly stable. During the late edit phase and finishing phase as more edit steps accrue, it gradually became more unstable.
I’ve observed this general pattern on many different large FCPX projects, on multiple machines, multiple macOS versions. So it’s not like trashing prefs, deleting render files, resetting SMC or re-installing macOS or FCPX will help — those have been done many times already, across multiple machines.
On this project in 10.4 there is an especially marked tendency to crash when applying multiple color correction steps. These are just built-in effects such as color wheels, color mask, shape mask, hue curves, etc. The call stack is usually as I posted above.
-
[Scott Witthaus] “When you say “pushing the software”, exactly what do you mean?”
Mine’s much simpler than Joe’s. Simple timeline of selects. Pulling clips from 20 or more 30min. TV shows. ProRes masters with stereo tracks. Just fast JKL of the source (or skimming), then I and O and append edit. Simple, but in very rapid succession. At some point in this process, FCPX simply stops updating the filmstrip image and then locks. Hard.
– Oliver
Oliver Peters – oliverpeters.com
-
With mine, I also add additional snapshot saves as I go. I prune those to keep the number reasonable but there could be maybe 15 or 20 before I delete some. The snapshots obviously add some stress because you can see it saying “loading…” However this is nothing extraordinary — it’s simply using the product as it was designed. I always have background rendering off.
It is difficult to say what specific factors contribute to the overall instability, since it has consistently happened across many machines, many versions of macOS and FCPX. With 10.4 there is an obvious issue with multiple color correction steps crashing it, and the call stack is very consistent. This specific issue isn’t for certain an FCPX issue, it could be a Metal library API or something else. But it usually manifests as FCPX itself hanging or crashing.
In previous versions the overall pattern is roughly similar — as the timeline gets more complex with more edit steps, and especially in the color grading phase where I’m adding hundreds of primary and secondary corrections, crashes and hangs become more common. My perception is having the scopes up makes it more likely but that could be coincidence — they are usually up when I’m doing color work. At the outset it might crash or hang every other day. As work progresses, it increases to once per day, then twice per day, then every few hours.
It’s not the platform, as it happens on multiple machines, multiple configurations, multiple RAID systems, multiple macOS versions, multiple FCPX versions. It’s not camera-specific media or a specific project because it happens on various projects and media from different cameras. In my particular case the source media is usually 4k H264 8-bit 4:2:0 100 mbps from a variety of cameras.
-
BTW – finishing the edit in question today and the same issue – several times. However, this time I simply waited out the beachball and FCPX eventually caught back up and recovered without crashing. More like a minute in each case today, but it’s a small and simple project and library.
FWIW – When I had the selects assembled, I XML’ed over to Premiere, where I’m continuing the rest of the edit. Much smoother.
– Oliver
Oliver Peters – oliverpeters.com
Reply to this Discussion! Login or Sign Up