FObjectFinder fails only in packaged game

Development Platform & Builds
, , , , ,
1

We’re able to successfully package our game for Windows with no errors, but the actual executable throws a null reference exception when loading the game mode’s DefaultPlayerPawn via FObjectFinder:

static ConstructorHelpers::FObjectFinder<UClass> PlayerPawnBPClass(TEXT("Class'/Game/Blueprints/NNRCharacterBP.NNRCharacterBP_C'"));
	if (PlayerPawnBPClass.Object != NULL)
	{
		DefaultPawnClass = PlayerPawnBPClass.Object;
	}

This works just fine when launching from the editor.

Here’s the relevant portion of the call stack.

 NNR-Win64-DebugGame.exe!LoadPackage(UPackage * InOuter, const wchar_t * InLongPackageName, unsigned int LoadFlags) Line 822	C++
 NNR-Win64-DebugGame.exe!StaticLoadObject(UClass * ObjectClass, UObject * InOuter, const wchar_t * InName, const wchar_t * Filename, unsigned int LoadFlags, UPackageMap * Sandbox, bool bAllowObjectReconciliation) Line 671	C++
>NNR-Win64-DebugGame.exe!ConstructorHelpersInternal::FindOrLoadObject<UClass>(FString & PathName) Line 31	C++

Unfortunately this is not a full-source project, but a separate C++ game module created via the editor New Project Wizard (is “content-only project” the proper designation for that?). This won’t allow me to see StaticLoadObject() or LoadPackage(), so I’m not able to follow what exactly is failing. Line 822 in UObjectGlobals.cpp corresponds to:

Linker->LinkerRoot->ThisRequiresLocalizationGather(Linker->RequiresLocalizationGather());

So something in there is null. “Linker” is checked for null prior to this line and the stack doesn’t show either function is entered, so I assume “LinkerRoot” is the culprit, but I’m not sure what to make of that.

I’m hoping I’ve just missed something simple and said enough to ring a bell for someone. Been at this for a while and would really appreciate any help. If you’d like more info please ask. Thanks everyone!

-Dan

Edit: Here’s the log

2

I felt I would report this here in case this is an engine bug. I had this same issue and upon debugging I found it was triggered by a circular dependency.

I’m assuming the engine allows circular dependencies to some degree, so I think it may be an engine bug. Specifically the crash occurs inside the LoadPackage() call you are refering too above, but the same package gets loaded recursively again as the result of Linker->LoadAllObjects(), and Linker->LinkerRoot is set to NULL at some point as the result of this.

I only noticed this when running with cooked data over a real network (it may also be a race condition kind of situation where if the package loads normally with the map because it is required in the map it is fine). It happened when the offending package is told to load as the result of replication of an object which needs the package (and LoadPackage is called from FNetGUIDCache::GetObjectFromNetGUID).

Not sure if the problem is on my end or an engine bug, but I felt I would share what I understand as best as I understand it in case it is an engine bug.

Note that I am running 4.4, so if it is an engine bug, it is there in the latest version.