Crash in FAsyncPackage2::EventDrivenCreateExport when loading blueprint

Development Platform & Builds
, ,
1

Hi

We’re experience a crash when loading in a blueprint. It’s caused by an existing actor whose blueprint was modified, but we aren’t clear why the specific modification is causing this crash.

We crash on the below code in EventDrivenCreateExport:

`// If we are about to create a CDO, we need to ensure that all parent sub-objects are loaded
// to get default value initialization to work.
#if DO_CHECK
if ((ObjectLoadFlags & RF_ClassDefaultObject) != 0)
{
UClass* SuperClass = LoadClass->GetSuperClass();
UObject* SuperCDO = SuperClass ? SuperClass->GetDefaultObject() : nullptr;
check(!SuperCDO || ExportObject.TemplateObject == SuperCDO); // the template for a CDO is the CDO of the super
if (SuperClass && !SuperClass->IsNative())
{
check(SuperCDO);
if (SuperClass->HasAnyFlags(RF_NeedLoad))
{
UE_LOG(LogStreaming, Fatal, TEXT(“Super %s had RF_NeedLoad while creating %s”), *SuperClass->GetFullName(), *ObjectName.ToString());
return;
}
if (SuperCDO->HasAnyFlags(RF_NeedLoad))
{
UE_LOG(LogStreaming, Fatal, TEXT(“Super CDO %s had RF_NeedLoad while creating %s”), *SuperCDO->GetFullName(), ObjectName.ToString());
return;
}
TArray<UObject> SuperSubObjects;
GetObjectsWithOuter(SuperCDO, SuperSubObjects, /bIncludeNestedObjects=/ false, /ExclusionFlags=/ RF_NoFlags, /InternalExclusionFlags=/ EInternalObjectFlags::Native);

for (UObject* SubObject : SuperSubObjects)
{
if (SubObject->HasAnyFlags(RF_NeedLoad))
{
UE_LOG(LogStreaming, Fatal, TEXT(“Super CDO subobject %s had RF_NeedLoad while creating %s”), *SubObject->GetFullName(), *ObjectName.ToString());
return;
}
}
}
else
{
// We crash HERE on the below check failing
checkf(ExportObject.TemplateObject->IsA(LoadClass),
TEXT(“ExportObject.TemplateObject: ‘%s’ is not a child of class: ‘%s’”),
*GetNameSafe(ExportObject.TemplateObject),
*GetNameSafe(LoadClass));
}
}`The TemplateObject is of a UActorComponent type. The LoadClass is a class derived from UActorComponent. The check seems backwards to me.

This is the only time that we try to asynchronously load a CDO from my testing. Do we know what could lead to us trying to load a CDO for a class component?

The component is a Non-SceneComponent that is attached to the parent blueprint for the blueprint for the actor we’re trying to load. Maybe the bug is that the non-scenecomponent is being streamed in asynchronously based on location?

Edit - Update 06/06:

We found a “fix” that works by reauthoring the change.

The actors were initially created from blueprint A, which derived from Actor. The broken change modified Blueprint A to derive from a new Blueprint B, while Blueprint B derived from Actor. This change crashed.

We made a version of the change where all of the logic in blueprint B was instead copied into Blueprint A, and Blueprint A’s parenting was not changed. That version does not crash.

2

Hello, thanks for sharing the update and the workaround you found for this problem. The blueprint being reparented sounds crucial for the repro. I’d like to see if we can reproduce this at will, because it would be nice to support reparented blueprints not to trigger that failing check. Do you recall what series of actions you took to create and modify the blueprint to run into that check? A repro project for this would be amazing, but I understand if you have other priorities now that you’re no longer blocked on this issue.

3

Hello! Apologies to necro this thread a year later, but I came across the same issue in the same place and wanted to provide some more information about how I solved it for anyone else that finds this. The fix for us was finding where the named asset (for us it was a component) was referenced in the project’s blueprints and essentially recreating it; this error for us indicated an asset corruption that we didn’t catch when it happened, and the editor was covering for us until we built. In the BP using the component, we deleted the component, recompiled/saved, and added the component back on & fixed up any nodes disturbed by the process. This cleared up the error when we built again. As for WHY this happened, I’m not sure; I know common causes of asset corruption are moves and renames, but we didn’t have either as far as we’re aware.