Crash after live coding when getting CDO/archetype for subobjects of a UMovieSceneSection subclass

Hi there,

We’ve been getting this intermittent live coding crash for a while, and just upgraded to 5.5 and are still getting it, so decided it could be worth reporting in case there’s something we’re doing wrong. It basically always happens when editing reflected headers, but swear it sometimes happens even if just editing implementations.

The error message is

Fatal error: [File:Engine\Source\Runtime\CoreUObject\Private\UObject\UObjectHash.cpp] [Line: 354]

Trying to modify UObject map (FindOrAdd) that is currently being iterated. Please make sure you’re not creating new UObjects or Garbage Collecting while iterating UObject hash tables.

We have some custom sequencer tracks/sections, and one specific section subclass seems to trigger a crash during reinstancing. From the call stack, it seems like it’s calling `UE::Reload::Private::UpdateDefaultProperties()` for the section subclass, then when that `ObjectPtr->GetDefaultSubobjects(DefaultSubobjectArray);` it ends up looping through via ForEachObjectWithOuter(), and ends up at the `UMovieSceneBuiltInEasingFunction EaseInFunction` of the base `UMovieSceneSection` (which is also created with `RF_Public` flag if that’s interesting).

When it’s checking `IsDefaultSubobject()` that ends up calling `this->GetArchetype()`, which in turn eventually calls `Class->GetDefaultObject()` (and doesn’t use the Authorative class since `bUseUpToDateClass` is false). Since that call doesn’t pass `bCreateIfNeeded` it ends up true, and I guess since its `ClassDefaultObject` is nullptr at this point it tries to allocate a new one via `StaticAllocateObject` which eventually calls into the UObject map FindOrAdd and panics.

I’ve tried to compare our custom section class to others in the engine and can’t really see much of a difference, so I’m wondering if there is some kind of engine bug with live coding and the combination or outers/flags that sequencer classes end up using?

Happy to provide more details as needed.

One other log right before this mentions `Error: VTable for class <SomeActorClass> did not change?` in case that’s relevant too.

Thanks,

Geordie

Edit: The callstack field doesn’t seem to show up, so will put here as well just in case:

UE::Logging::Private::BasicFatalLog(const FLogCategoryBase &,const UE::Logging::Private::FStaticBasicLogRecord *,...) StructuredLog.cpp:1104
[Inlined] TBucketMap::FindOrAdd(UObjectBase *&&) UObjectHash.cpp:354
[Inlined] AddToOuterMap(FUObjectHashTables &, UObjectBase *) UObjectHash.cpp:991
HashObject(UObjectBase *) UObjectHash.cpp:1613
UObjectBase::AddObject(FName, EInternalObjectFlags, int, int) UObjectBase.cpp:220
UObjectBase::UObjectBase(UClass *, EObjectFlags, EInternalObjectFlags, UObject *, FName, int, int) UObjectBase.cpp:135
StaticAllocateObject(const UClass *, UObject *, FName, EObjectFlags, EInternalObjectFlags, bool, bool *, UPackage *) UObjectGlobals.cpp:3614
UClass::CreateDefaultObject() Class.cpp:4867
UClass::InternalCreateDefaultObjectWrapper() Class.cpp:5492
[Inlined] UClass::GetDefaultObject(bool) Class.h:3409
GetArchetypeFromRequiredInfoImpl(const UClass *, const UObject *, FName, EObjectFlags, bool, const FObjectArchetypeHelper::IObjectArchetypePolicy *) UObjectArchetype.cpp:167
`GetArchetypeFromRequiredInfoImpl'::`10'::<lambda_1>::operator()() UObjectArchetype.cpp:119
[Inlined] AutoRTFM::Open(const <lambda_1> &) AutoRTFM.h:677
GetArchetypeFromRequiredInfoImpl(const UClass *, const UObject *, FName, EObjectFlags, bool, const FObjectArchetypeHelper::IObjectArchetypePolicy *) UObjectArchetype.cpp:97
`GetArchetypeFromRequiredInfoImpl'::`10'::<lambda_1>::operator()() UObjectArchetype.cpp:119
[Inlined] AutoRTFM::Open(const <lambda_1> &) AutoRTFM.h:677
GetArchetypeFromRequiredInfoImpl(const UClass *, const UObject *, FName, EObjectFlags, bool, const FObjectArchetypeHelper::IObjectArchetypePolicy *) UObjectArchetype.cpp:97
GetArchetypeImpl(const UObject *, const FObjectArchetypeHelper::IObjectArchetypePolicy *) UObjectArchetype.cpp:263
[Inlined] UObject::GetArchetype() UObjectArchetype.cpp:269
UObjectBaseUtility::IsDefaultSubobject() UObjectBaseUtility.cpp:528
`UObject::GetDefaultSubobjects'::`2'::<lambda_1>::operator()(UObject *) Obj.cpp:184
[Inlined] UE::Core::Private::Function::TFunctionRefBase::operator()(UObject *) Function.h:470
[Inlined] ForEachObjectWithOuter::__l2::<lambda_1>::operator()(UObject *) UObjectHash.h:134
[Inlined] Invoke(ForEachObjectWithOuter::__l2::<lambda_1> &, UObject *&&) Invoke.h:47
UE::Core::Private::Function::TFunctionRefCaller<`ForEachObjectWithOuter'::`2'::<lambda_1>,bool,UObject *>::Call(void *,UObject *&) Function.h:319
[Inlined] UE::Core::Private::Function::TFunctionRefBase::operator()(UObject *) Function.h:470
ForEachObjectWithOuterBreakable(const UObjectBase *, TFunctionRef<…>, bool, EObjectFlags, EInternalObjectFlags) UObjectHash.cpp:1279
[Inlined] ForEachObjectWithOuter(const UObjectBase *, TFunctionRef<…>, bool, EObjectFlags, EInternalObjectFlags) UObjectHash.h:134
UObject::GetDefaultSubobjects(TArray<…> &) Obj.cpp:182
UE::Reload::Private::UpdateDefaultProperties(UClass *, const UE::Reload::Private::FCDOPropertyData &, const UE::Reload::Private::FCDOPropertyData &) ReloadUtilities.cpp:552
UE::Reload::Private::FReloadClassHelper::ReinstanceClass(UClass *, UE::Reload::Private::FReloadClassHelper::ClassReinstanceState &) ReloadUtilities.cpp:743
UE::Reload::Private::FReloadClassHelper::ReinstanceClasses(const TMap<…> &) ReloadUtilities.cpp:689
FReload::Reinstance() ReloadUtilities.cpp:1140
ProcessNewlyLoadedUObjects(FName, bool) UObjectBase.cpp:920
FLiveCodingModule::AttemptSyncLivePatching() LiveCodingModule.cpp:863
[Inlined] Invoke(void (FLiveCodingModule::*)(), FLiveCodingModule *&) Invoke.h:66
[Inlined] UE::Core::Private::Tuple::TTupleBase::ApplyAfter(void (FLiveCodingModule::*&)(), FLiveCodingModule *&) Tuple.h:317
TBaseRawMethodDelegateInstance::ExecuteIfSafe() DelegateInstancesImpl.h:533
[Inlined] TMulticastDelegateBase::Broadcast() MulticastDelegateBase.h:257
TMulticastDelegate::Broadcast() DelegateSignatureImpl.inl:1079
FEngineLoop::Tick() LaunchEngineLoop.cpp:6121
[Inlined] EngineTick() Launch.cpp:69
GuardedMain(const wchar_t *) Launch.cpp:190
LaunchWindowsStartup(HINSTANCE__ *, HINSTANCE__ *, char *, int, const wchar_t *) LaunchWindows.cpp:266
WinMain(HINSTANCE__ *, HINSTANCE__ *, char *, int) LaunchWindows.cpp:317
[Inlined] invoke_main() 0x00007ff67189f0ca
__scrt_common_main_seh() 0x00007ff67189f0a9
<unknown> 0x00007ff8abf0259d
<unknown> 0x00007ff8acccaf38

We also get ‘Invalid object reference’ errors when reinstancing fairly regularly if that’s of interest too, eg.

Invalid object referenced by the PersistentFrame: 0x00000845851b2a80 
Blueprint object: AnimBlueprint /Game/Redacted/abp_Redacted.abp_Redacted
ReferencingProperty: ObjectProperty /Game/Redacted/abp_Redacted.abp_Redacted_C:ExecuteUbergraph_abp_Redacted:CallFunc_GetEngineSubsystem_ReturnValue
Instance: abp_Redacted_C /Game/Redacted/map_Redacted.map_Redacted:PersistentLevel.bp_RedactedCharacter_C_0.SkeletalMeshComponent.abp_Redacted_C_0
Address: 0x000008459384dc88) - 
If you have a reliable repro for this, please contact the development team with it.

Steps to Reproduce

Hi there, just bumping this since never heard back. I still get this crash fairly reliably, and it’s really annoying not being able to use LiveCoding.

Hi,

Thanks for reporting and sorry for the very long delay, Live Coding do not have an active owner and the ticket was left unattended. I took a look at your issue and I reported it in JIRA (UE-320826), we also have a very similar one still open (UE-228193 that was reported in Fortnite in October 2024), so I linked both JIRAs together. I don’t know if this is going to be investigated, but it is reported. The sequencer team also use Live Coding regularly and they don’t get this crash, so they suspected the issue might be something in the subclass, but I didn’t get more information.

As a side note, we are planning to upgrade to Live++ 2, some work was done, but it’s still incomplete and Live Coding doesn’t get all the attention is should.

Regards,

Patrick

FYI, starting with UE 5.6, you could try setting turning on live++ 2

/Engine/Source/Developer/Windows/LiveCoding/LiveCoding.Build.cs

static bool UseLiveCoding2 = true;The feature was not QA, but apparently, people on the Fortnite team are using it.

Regards,

Patrick

Hi Geordie,

If you try it with UE 5.6, you may also want to cherry pick CL 43321617 from Main. I noticed this CL fixing an annoying bug yesterday while I was reading through our Live Coding slack threads.

Regards,

Patrick

Oh thanks Patrick, sorry for the delayed response on my end too! We’re on 5.6 so I’ll definitely try that.

I actually haven’t seen too many live coding crashes from this particular moviescene related object recently, but we still get lots of crashes from other things like ChildActorComponents so it still isn’t really viable on this project. Would love to track it down more but hard to know what’s due to us doing weird (particularly BP) stuff at edit-time and what’s just engine bugs.

Cheers,

Geordie