@bbb_999 Wanted to give you a heads up that I’m experiencing significantly more crashes on the latest version of PPro Beta 27.0 than I was before the 27.0 update. It seems that there may be some new type of UXP API object mutation race condition.
My agent looked at the crash dump and believes it is the background ML analysis for Semantic Auto Tone racing against UXP. Take that with a grain of salt of course. Here is the faulting stack:
dvacore::config::DoThrowNullPtrException(std::type_info const&)
ML::BackgroundAnalysis::TrackerManager::AddAnalyzerForTrackItem(BE::ITrackItem const&, BE::IComponent const&, shared_ptr<ML::BackgroundAnalysis::TrackItemTracker>)
ML::BackgroundAnalysis::TrackerManager::AddAnalyzerForTrackItem<ML::SemanticAutoTone::SemanticAutoToneTracker>(...)
ML::StartMonitoringTrackItemForBackgroundAnalysisIfNeeded(BE::ITrackItem const&)
→ dvacore::config::Panic → Abort (SIGABRT)
What I can say for sure is that the Beta versions prior to 27.0 cut down on PPro crashes noticeably, but the incidence rate of crashing is back to the same rate as PPro stable 26.3.2, which in my case is about 25% of the time that I use my plugin (we do hundreds of rapid UXP API calls per plugin action, so my case is far more likely to produce a race condition than other plugin types).
If you have any advice on what I can do to reduce the probability of having a full PPro crash while using UXP I’d greatly appreciate it. I’m guessing that the only mitigation strategy at this point is to reduce the total number of object mutating UXP API calls though. I’ve been bit enough times from race condition crashes that we will likely need to migrate as many media edit operations outside of Premiere UXP as possible and just use it as a basic compositor if there isn’t some kind of mitigation strategy I can implement.
Thanks again. I know you guys are building UXP on a mountain of complex tech debt and understand how difficult of a problem this is. Keep up the good work!
