There seems to be a pattern of unsolved bug reports with asserts on Map and/or Set adds recently:
and now a third variety that we’re seeing:
Assertion failed: !AllocationFlags[Index] [File:Runtime\Core\Public\Containers/SparseArray.h] [Line: 87]
tracksidegepoc!FDebug::AssertFailed()
tracksidegepoc!TSparseArray<TSetElement<TTuple<UAnimMontage * __ptr64,FAnimMontageInstance * __ptr64> >,TSparseArrayAllocator<FDefaultAllocator,FDefaultBitArrayAllocator> >::AllocateIndex()
tracksidegepoc!TSet<TTuple<UAnimMontage * __ptr64,FAnimMontageInstance * __ptr64>,TDefaultMapHashableKeyFuncs<UAnimMontage * __ptr64,FAnimMontageInstance * __ptr64,0>,FDefaultSetAllocator>::Emplace<TPairInitializer<UAnimMontage * __ptr64 const & __ptr64,FAni()
tracksidegepoc!UAnimInstance::Montage_Play()
tracksidegepoc!UAnimInstance::execMontage_Play()
tracksidegepoc!UFunction::Invoke()
tracksidegepoc!UObject::CallFunction()
tracksidegepoc!UObject::execLet()
tracksidegepoc!UObject::ProcessInternal()
tracksidegepoc!UObject::CallFunction()
tracksidegepoc!UObject::ProcessInternal()
tracksidegepoc!UObject::CallFunction()
tracksidegepoc!UObject::ProcessContextOpcode()
tracksidegepoc!UObject::ProcessInternal()
tracksidegepoc!UFunction::Invoke()
tracksidegepoc!UObject::ProcessEvent()
tracksidegepoc!AActor::ProcessEvent()
tracksidegepoc!FLatentActionManager::TickLatentActionForObject()
tracksidegepoc!FLatentActionManager::ProcessLatentActions()
tracksidegepoc!AActor::Tick()
since we upgraded from 4.19 to 4.21. We’ve only seen it after running overnight, but it doesn’t appear to be a leak or memory issue.
Between the three cases, it’s hard to imagine it could be coincidence. Anyone have an idea? My gut feeling says it’s a concurrency issue.
Edit: I’ve found a very similar bug that was fixed many versions ago: