Closed stevef243 closed 5 months ago
0 libobjc.A.dylib 0x00000001816fd420 objc_msgSend + 32
1 com.apple.compressor.MediaServerAPI 0x000000028c6ebb4c CSimpleMediaProviderClientInProcess::renderFrameInto(long long, CRenderBufferRef const&) + 340
2 com.apple.compressor.StompTypes 0x000000028cb2fcd8 stomp::CMediaServerMediaDecoder::decodeFrame(long long, CRenderBufferRef const&, bool, bool) + 232
3 com.apple.compressor.StompTypes 0x000000028cb4f4c4 CHeliumFrameControlsProcessor::HeliumGetCVPixelBuffer(CMTime, __CVBuffer**, void*) + 556
4 com.apple.HeliumSenso 0x0000000101f7a9f8 InputJob::RenderCallback(HGRenderer*) + 208
5 com.apple.HeliumSenso 0x0000000101fe11b4 SOProvider::HandleJobStateExecuting(SOProvider::CustomJobData*, HGRenderer*) + 500
6 com.apple.HeliumSenso 0x0000000101fe19a8 SOProvider::UserJobNotifyFunc(HGUserJob*) + 180
7 com.apple.Helium 0x0000000102bd7938 HGUserJob::CallNotifyFunc() + 48
8 com.apple.Helium 0x0000000102c3f3d4 HGUserExecUnit::RunLoop() + 172
9 com.apple.Helium 0x0000000102c3f318 StartUserExecUnitFunc(void*) + 20
10 libsystem_pthread.dylib 0x0000000181aca034 _pthread_start + 136
11 libsystem_pthread.dylib 0x0000000181ac4e3c thread_start + 8
I am suspicious this might be related to the new 10.7.0 feature called "export segmentation", and apparently using CompressorKit.parallelizedTranscode. On certain Apple Silicon hardware platforms, export of certain H264 and HEVC timelines may attempt to use parallel encoding by concurrent use of multiple media engines. Each of these crashes have one or more threads doing that. That might be exposing a race condition. The threads doing parallel transcoding are not themselves crashing but they could easily mismanage a synchronization object that crashes other threads.
It would be interesting to try disabling “Allow export segmentation”, which is enabled by default in the Share window -- if conditions for export segmentations are met. Otherwise the option does not appear in the Share UI. If that prevents the problem, it would be an immediate workaround, plus it would tend to corroborate this as the cause.
See "Speed up exports with simultaneous processing in Final Cut Pro for Mac": https://support.apple.com/guide/final-cut-pro/speed-up-exports-with-simultaneous-processing-verd006aab15/mac
It could be. However, I fixed it by spending a lot of time going through every one of the nearly hundred clips, chacking where stabilisation was applied, and re-checking the stabilisation box. Unfortunately, this is also something that goes on for quite some time in FCP that it often can't even use the built-in features properly and then provides a error message without pointing out the clip with the issue is even worse.
I am suspicious this might be related to the new 10.7.0 feature called "export segmentation", and apparently using CompressorKit.parallelizedTranscode. On certain Apple Silicon hardware platforms, export of certain H264 and HEVC timelines may attempt to use parallel encoding by concurrent use of multiple media engines. Each of these crashes have one or more threads doing that. That might be exposing a race condition. The threads doing parallel transcoding are not themselves crashing but they could easily mismanage a synchronization object that crashes other threads.
It would be interesting to try disabling “Allow export segmentation”, which is enabled by default in the Share window -- if conditions for export segmentations are met. Otherwise the option does not appear in the Share UI. If that prevents the problem, it would be an immediate workaround, plus it would tend to corroborate this as the cause.
See "Speed up exports with simultaneous processing in Final Cut Pro for Mac": https://support.apple.com/guide/final-cut-pro/speed-up-exports-with-simultaneous-processing-verd006aab15/mac
Hm you could be right. again issue during export with FCP crashing once disabling simultaneous processing as well as deleting all renders and re-rendering it worked
If you still have the crash log (see here), can you show what Thread 82 says? When sharing crash logs it's important to show the actual crashed thread.
Here's the crashed thread in question:
Thread 82 Crashed:: com.apple.helium-render-queue-exec-unit-user
0 libobjc.A.dylib 0x0000000189015420 objc_msgSend + 32
1 com.apple.compressor.MediaServerAPI 0x00000002831dfb4c CSimpleMediaProviderClientInProcess::renderFrameInto(long long, CRenderBufferRef const&) + 340
2 com.apple.compressor.StompTypes 0x0000000283c53cd8 stomp::CMediaServerMediaDecoder::decodeFrame(long long, CRenderBufferRef const&, bool, bool) + 232
3 com.apple.compressor.StompTypes 0x0000000283c734c4 CHeliumFrameControlsProcessor::HeliumGetCVPixelBuffer(CMTime, __CVBuffer**, void*) + 556
4 com.apple.HeliumSenso 0x000000010434a9f8 InputJob::RenderCallback(HGRenderer*) + 208
5 com.apple.HeliumSenso 0x00000001043b11b4 SOProvider::HandleJobStateExecuting(SOProvider::CustomJobData*, HGRenderer*) + 500
6 com.apple.HeliumSenso 0x00000001043b19a8 SOProvider::UserJobNotifyFunc(HGUserJob*) + 180
7 com.apple.Helium 0x0000000104fa7938 HGUserJob::CallNotifyFunc() + 48
8 com.apple.Helium 0x000000010500f3d4 HGUserExecUnit::RunLoop() + 172
9 com.apple.Helium 0x000000010500f318 StartUserExecUnitFunc(void*) + 20
10 libsystem_pthread.dylib 0x00000001893e2034 _pthread_start + 136
11 libsystem_pthread.dylib 0x00000001893dce3c thread_start + 8
Are you sending to Compressor, or exporting via Final Cut Pro? Are you using a Compressor Share Destination?
nop straight from FCP Apple Device 4k segementation was enabled
Here's the crashed thread in question:
Thread 82 Crashed:: com.apple.helium-render-queue-exec-unit-user 0 libobjc.A.dylib 0x0000000189015420 objc_msgSend + 32 1 com.apple.compressor.MediaServerAPI 0x00000002831dfb4c CSimpleMediaProviderClientInProcess::renderFrameInto(long long, CRenderBufferRef const&) + 340 2 com.apple.compressor.StompTypes 0x0000000283c53cd8 stomp::CMediaServerMediaDecoder::decodeFrame(long long, CRenderBufferRef const&, bool, bool) + 232 3 com.apple.compressor.StompTypes 0x0000000283c734c4 CHeliumFrameControlsProcessor::HeliumGetCVPixelBuffer(CMTime, __CVBuffer**, void*) + 556 4 com.apple.HeliumSenso 0x000000010434a9f8 InputJob::RenderCallback(HGRenderer*) + 208 5 com.apple.HeliumSenso 0x00000001043b11b4 SOProvider::HandleJobStateExecuting(SOProvider::CustomJobData*, HGRenderer*) + 500 6 com.apple.HeliumSenso 0x00000001043b19a8 SOProvider::UserJobNotifyFunc(HGUserJob*) + 180 7 com.apple.Helium 0x0000000104fa7938 HGUserJob::CallNotifyFunc() + 48 8 com.apple.Helium 0x000000010500f3d4 HGUserExecUnit::RunLoop() + 172 9 com.apple.Helium 0x000000010500f318 StartUserExecUnitFunc(void*) + 20 10 libsystem_pthread.dylib 0x00000001893e2034 _pthread_start + 136 11 libsystem_pthread.dylib 0x00000001893dce3c thread_start + 8
Are you sending to Compressor, or exporting via Final Cut Pro? Are you using a Compressor Share Destination?
does not mean much to me. Does it give you some indication of what is going on?
Steve, could you clarify whether "export segmentation" was enabled or disabled in the above crash? Your previous comment about this implied that with export segmentation disabled and cache deleted, the export did not crash. Is that correct? If so is that consistent?
The last crash log looks like it was doing parallelized encoding on threads 66, 67 and 68, which implies export segmentation. It appears FCP implements that by call the CompressorKit framework, even if you aren't using the Compressor app.
Thread 12 had a very long backtrace involving a lot of classes and methods in the Ozone framework. Frame 30 shows several classes and methods possibly related to VR360. Are any VR360 or similar effects used in this timeline?
As we proceed up the backtrace of thread 12 at frame 6, we see several TXT-related functions. Are any titles or similar effects used? Any info like this might help narrow down the source of the problem.
In frame 1 of thread 12, we see OZLockingGroup, which might manage synchronization for a group of related objects or data structures. The WriteSentry destructor suggests a write lock was held and is now being released.
All threads exist within the same address space, and FCP intermixes both UNIX-like "pthreads" Grand Central Dispatch threads. That may related to the source code evolution to the more abstract threading methods.
Chris and I have lots of software debugging experience, but fixing things like this usually requires achieving a reproducible failure scenario. It is difficult for a developer to reliably fix a problem solely from a crash log.
Is this crash-on-export problem consistent? Is it tied to a specific timeline? Does it only happen when export segmentation is enabled? Do any of my above comments ring any bells, ie VR360, titles or other text-based effects? Are you using any FCP built-in generators? If so, which ones?
If you duplicate the timeline, open the duplicate, delete the first half and export it, does that crash? What about the second half? Or is the crash on export intermittent, even with the full timeline?
There is a bug with the "Drifting" generator that can cause a hang or crash during rendering or export (varies based on Intel vs Apple Silicon, and type of GPU). I am still investigating that. I think it is isolated to that one generator but I'm not sure.
When it crashed export segmentation was enabled, I gave it 3 different attempts and it crashed every time. Unfortunately I forgot to try with segmentation disabled at the time
After deleting all rendered file, re-rendering everything the error did not come up and it exported fine with segmentation disabled.
Not sure what VR360 is but not used anywhere as far as I'm aware, however there are some text based effects used.
It has happened on a few occasions but it's not reproducible as such.
Very hard to do extensive testing as I'm under time constraints and need to finish this project before I travel again
Apple Feedback Assistant ID: FB13515704
DESCRIBE THE BUG: FCP Crashing during file export
TO REPRODUCE: Exporting file
EXPECTED BEHAVIOUR: not crashing
CRASH LOGS:
SPECS: