I’m getting an error when I try to launch my packaged game from 4.8 binary build. I’m packaging from Windows 8, have tried 32/64-bit packaging and DebugGame/Development builds.
[2015.06.15-01.33.32:311][ 0]LogWindows: === Critical error: ===
Fatal error: [File:D:\BuildFarm\buildmachine_++depot+UE4-Releases+4.8\Engine\Source\Runtime\CoreUObject\Private\UObject\GarbageCollection.cpp] [Line: 1894]
Unknown token type (8) when trying to add ARO token.
Here is the [full log][1].
And here is a screenshot of the stack trace (stack trace doesn’t show in logs), I don’t see any of my code in this stack.
I can also get this stack trace when simply launching DebugGame from Visual Studio. The stack is bogus, I don’t have source for any of the items on the stack, it’s all windows code.
It’s interesting to note that I get the same stack when launching the packaged game on android as well but everything works just fine in the editor.
I’m guessing I’ll have to grab the source version of the engine so that I can print out object names as they zip through the token stream function and see which class might be the problem class. What a mess.
I’ve managed to track down the offending class to a HUD class whose base is UUserWidget. I don’t see anything odd with this class, so the hunt continues, maybe some odd uproperty or something that’s causing the ARO token type to be unknown.
I’ve retitled/tagged this. The issue is that ReplaceOrAddAddReferencedObjectsCall in GarbageCollection.cpp does not have a case for the TMap token despite the UPROPERTY system now supporting it. This causes the error due to unknown token type (8) GCRT_AddTMapReferencedObjects.
The solution on my end was to remove UPROPERTY from my TMap to prevent the error and use the old workaround of double-stuffing objects into a TArray to prevent GC.
To test this I’d have to undo a lot of work-around code that took a long time to put in place, so I won’t be potentially destabilizing our codebase to test this. If it helps though, I pulled down the promoted build on 6/22/2015 and tracked down the issue using that build. You can commit match a specific fix to see if there’s a match, but the last change I see to the relevant tree is [2589115][1] which was from the 18th. So 90% sure this problem still exists.
[1]: https://github.com/EpicGames/UnrealEngine/commit/ae9aa0ed8424ed3041f5b1da215ac41b9a2e7112
I haven’t managed to repro the problem with the class definitions you provided (it’s possibly now masked by other recent changes), but I have checked in that fix anyway, as I believe it is correct:
