After upgrading a large (>2mln assets) project from UE 5.5 to UE 5.7, cooking crashes deterministically during asset registry generation with:
Fatal error: Trying to resize TArray to an invalid size of 3'584'574'257
The crash occurs in FixedTagPrivate::FStoreBuilder::Finalize() while flattening AnsiStrings.
This happens when initializing the platform asset registry from the existing global registry state, before any actual cooking work begins.
In UE 5.7, InitializeFromExisting() builds a single FixedTag store for the entire asset set by accumulating all tag maps into one FStoreBuilder and calling Finalize() once. For large projects like we have, this causes FStoreBuilder::Finalize() to attempt to flatten all tag strings into a single AnsiStrings array, resulting in an unbounded allocation request (multi-GB) and triggering OnInvalidArrayNum().
In UE 5.5, the asset registry state was still rebuilt node-by-node, but the FixedTag store construction did not aggregate tag data for the entire asset set into a single global builder/finalization pass, which avoided the pathological large allocation seen in UE 5.7.
The issue appears to be introduced by the following change, which consolidates tag-store construction across the full asset registry.
Reverting the relevant portion of FAssetRegistryState::InitializeFromExisting() to UE 5.5 behavior (or otherwise reintroducing chunked/incremental FixedTag store construction) avoids the crash and allows cooking to complete successfully.
This regression makes cooking large projects infeasible on UE 5.7 due to unbounded memory allocation during asset registry initialization, even when all asset data is valid.
[Attachment Removed]
A single large allocation is possibly more memory efficient for the remaining duration of the cook because of a larger range of data that can be deduplicated inside of the single FStore.
Can you post the callstack? I’m curious which TArray is getting too big, maybe we can fix the issue by changing it to a TArray64. Possibly it’s this one which was reported by another licensee and we changed to a TArray64 already:
20abed765bdceef8889af782852bde2c86897b45 aka CL 49627530 `AssetRegistry: Remove 2GB limit on loading DevelopmentAssetRegistry.bin files that was imposed by AssetDataTagMap.cpp…`
[Attachment Removed]
Hi Matt,
Thank you for the prompt reply.
Sorry, I thought it has already been attached:
LogWindows: Error: Fatal error: [File:Engine\Source\Runtime\Core\Private\Containers\ContainerHelpers.cpp] [Line: 8]
LogWindows: Error: Trying to resize TArray to an invalid size of 3584574257
LogWindows: Error: [Callstack] 0x00007ffba163d29a UnrealEditor-Core.dll!UE::Core::Private::OnInvalidArrayNum() [Engine\Source\Runtime\Core\Private\Containers\ContainerHelpers.cpp:8]
LogWindows: Error: [Callstack] 0x00007ffba0982d2f UnrealEditor-CoreUObject.dll!FixedTagPrivate::FlattenAndConcatenateAs<char,TMap<FString,unsigned int,FDefaultSetAllocator,FixedTagPrivate::FStoreBuilder::FCaseSensitiveFuncs<unsigned int> > >() [Engine\Source\Runtime\CoreUObject\Private\AssetRegistry\AssetDataTagMap.cpp:810]
LogWindows: Error: [Callstack] 0x00007ffba09b870e UnrealEditor-CoreUObject.dll!FixedTagPrivate::FStoreBuilder::Finalize() [Engine\Source\Runtime\CoreUObject\Private\AssetRegistry\AssetDataTagMap.cpp:868]
LogWindows: Error: [Callstack] 0x00007ffba09c7998 UnrealEditor-CoreUObject.dll!FixedTagPrivate::InitializeFromBuilder() [Engine\Source\Runtime\CoreUObject\Private\AssetRegistry\AssetDataTagMap.cpp:1394]
LogWindows: Error: [Callstack] 0x00007ffb931021cd UnrealEditor-AssetRegistry.dll!FAssetRegistryState::InitializeFromExisting() [Engine\Source\Runtime\AssetRegistry\Private\AssetRegistryState.cpp:635]
LogWindows: Error: [Callstack] 0x00007ffb931b54e9 UnrealEditor-AssetRegistry.dll!UAssetRegistryImpl::InitializeTemporaryAssetRegistryState() [Engine\Source\Runtime\AssetRegistry\Private\AssetRegistry.cpp:6690]
LogWindows: Error: [Callstack] 0x00007ffb94d29bbc UnrealEditor-UnrealEd.dll!FAssetRegistryGenerator::Initialize() [Engine\Source\Editor\UnrealEd\Private\Commandlets\AssetRegistryGenerator.cpp:1322]
LogWindows: Error: [Callstack] 0x00007ffb95f5e3ae UnrealEditor-UnrealEd.dll!UCookOnTheFlyServer::RefreshPlatformAssetRegistries() [Engine\Source\Editor\UnrealEd\Private\CookOnTheFlyServer.cpp:8260]
LogWindows: Error: [Callstack] 0x00007ffb95f68cfa UnrealEditor-UnrealEd.dll!UCookOnTheFlyServer::StartCookByTheBook() [Engine\Source\Editor\UnrealEd\Private\CookOnTheFlyServer.cpp:10966]
LogWindows: Error: [Callstack] 0x00007ffb94dba946 UnrealEditor-UnrealEd.dll!UCookCommandlet::RunCookByTheBookCook() [Engine\Source\Editor\UnrealEd\Private\Commandlets\CookCommandlet.cpp:600]
LogWindows: Error: [Callstack] 0x00007ffb94d80066 UnrealEditor-UnrealEd.dll!UCookCommandlet::CookByTheBook() [Engine\Source\Editor\UnrealEd\Private\Commandlets\CookCommandlet.cpp:559]
LogWindows: Error: [Callstack] 0x00007ffb94da0163 UnrealEditor-UnrealEd.dll!UCookCommandlet::Main() [Engine\Source\Editor\UnrealEd\Private\Commandlets\CookCommandlet.cpp:278]
LogWindows: Error: [Callstack] 0x00007ff6926fc868 UnrealEditor-Cmd.exe!FEngineLoop::PreInitPostStartupScreen() [Engine\Source\Runtime\Launch\Private\LaunchEngineLoop.cpp:4059]
LogWindows: Error: [Callstack] 0x00007ff6926f2910 UnrealEditor-Cmd.exe!GuardedMain() [Engine\Source\Runtime\Launch\Private\Launch.cpp:169]
LogWindows: Error: [Callstack] 0x00007ff6926f323a UnrealEditor-Cmd.exe!GuardedMainWrapper() [Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:123]
LogWindows: Error: [Callstack] 0x00007ff6926f68ee UnrealEditor-Cmd.exe!LaunchWindowsStartup() [Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:277]
LogWindows: Error: [Callstack] 0x00007ff692708af4 UnrealEditor-Cmd.exe!WinMain() [Engine\Source\Runtime\Launch\Private\Windows\LaunchWindows.cpp:334]
LogWindows: Error: [Callstack] 0x00007ff69270b61e UnrealEditor-Cmd.exe!__scrt_common_main_seh() [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288]
LogWindows: Error: [Callstack] 0x00007ffc5aeae8d7 KERNEL32.DLL!UnknownFunction []
LogWindows: Error: [Callstack] 0x00007ffc5cfbfbcc ntdll.dll!UnknownFunction []
Indeed it could be the one causing an overflow, thanks. Will give that a try.
[Attachment Removed]
I spoke to soon, the correct array in may case is FStoreData::AnsiStrings, so looks like the fix above won’t help.
[Attachment Removed]
I am working on fixing this in 5.8, and will provide a shelf to fix it in 5.7.
I am changing AnsiStrings and WideStrings to be TArray64.
[Attachment Removed]
After some internal discussion, we now think that fixing the TagsDatabase to handle more than 2GB of data is not the best solution because it will be poor performance.
We think that we should instead remove the FiBData from the AssetRegistry, as that is the only tag source that is pushing data over 2GB for licensees.
Furthermore, you should be able to workaround that issue now by removing the FiBData from your cooked assetregistry. Can you test whether adding this Blacklist element to your ini fixes your issue?
Config\DefaultEngine.ini
[AssetRegistry]
; Additional CookedTagsBlacklist elements, see also Engine\Config\BaseEngine.ini
+CookedTagsBlacklist=(Class=*,Tag=FiBData)
If that does not fix the issue, then can you run the editor with
-logcmds="LogAssetRegistry verbose"
and let me know which classes are reported to have large tags in the log lines that start with
LogAssetRegistry: Verbose: TagMemoryUse:
<Class and size data reported here>
[Attachment Removed]
Thanks, that large amount of data in World and StaticMeshActor makes it likely that you are affected by the tags just reported by another licensee.
Two other licensees reported that adding the exclusion for FiBData did not help, and that the remaining size came from actor labels.
Instead of adding the exclusion for FiBData, can you add these tags and test whether it fixes the issue for you?
+CookedTagsBlacklist=(Class=*,Tag=ActorMetaData)
+CookedTagsBlacklist=(Class=*,Tag=ActorsMetaData)
+CookedTagsBlacklist=(Class=*,Tag=ActorMetaDataClass)
+CookedTagsBlacklist=(Class=*,Tag=ActorLabel)
Those are safe to remove from all projects by default so I will be adding them to BaseEngine.ini.
I think that exclusion will solve the issue for all current licensees, so we won’t work on adding 64-bit AnsiString support to TagDataMap for now. Let me know if that’s not the case for you and we still need to add it to support your project.
[Attachment Removed]