CesiumGS / cesium-unreal

Bringing the 3D geospatial ecosystem to Unreal Engine
https://cesium.com/platform/cesium-for-unreal/
Apache License 2.0
879 stars 285 forks source link

FName Overflow, allocated 1024MB of string data. FName strings are never freed and should be created sparingly. Some system might be generating too many FNames, see call stack. #1422

Closed mcleantom closed 1 month ago

mcleantom commented 1 month ago

When I run my application for several hours (at least 5 hours) I get the error:

[2024.05.10-16.21.29:800][693]LogStreaming: Display: 0.160 ms for processing 89658 objects in RemoveUnreachableObjects(Queued=0, Async=0). Removed 0 (537->537) packages and 0 (1573->1573) public exports.
Assertion failed: CurrentBlock < FNameMaxBlocks [File:D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Private\UObject\UnrealNames.cpp] [Line: 698] 
FName overflow, allocated 1024MB of string data. FName strings are never freed and should be created sparingly. Some system might be generating too many FNames, see call stack. 

The stack trace of this comes from Cesium:

    INEOS-Win64-DebugGame.exe!FNameEntryAllocator::AllocateNewBlock(void)   C++
    INEOS-Win64-DebugGame.exe!FNamePoolShard<1>::CreateAndInsertEntry<class FWriteScopeLock>(struct FNameSlot &,struct FNameValue<1> const &)   C++
    INEOS-Win64-DebugGame.exe!FNamePool::Store(struct FNameStringView)  C++
    INEOS-Win64-DebugGame.exe!FNameHelper::FindOrStoreString(struct FNameStringView,enum EFindName) C++
    INEOS-Win64-DebugGame.exe!FNameHelper::MakeWithNumber(struct FWideStringViewWithWidth,enum EFindName,int)   C++
    INEOS-Win64-DebugGame.exe!FName::FName(wchar_t const *,enum EFindName)  C++
    INEOS-Win64-DebugGame.exe!FStatNameAndInfo::ToLongName(class FName,char const *,char const *,wchar_t const *,bool)  C++
    INEOS-Win64-DebugGame.exe!FStatMessage::FStatMessage(class FName,enum EStatDataType::Type,char const *,char const *,wchar_t const *,bool,bool,bool,enum FWindowsPlatformMemory::EMemoryCounterRegion)   C++
    INEOS-Win64-DebugGame.exe!FStartupMessages::AddMetadata(class FName,wchar_t const *,char const *,char const *,wchar_t const *,bool,enum EStatDataType::Type,bool,bool,enum FWindowsPlatformMemory::EMemoryCounterRegion)    C++
    INEOS-Win64-DebugGame.exe!FUObjectItem::CreateStatID(void)  C++
    INEOS-Win64-DebugGame.exe!FPrimitiveSceneProxy::FPrimitiveSceneProxy(class UPrimitiveComponent const *,class FName) C++
    INEOS-Win64-DebugGame.exe!FStaticMeshSceneProxy::FStaticMeshSceneProxy(class UStaticMeshComponent *,bool)   C++
    INEOS-Win64-DebugGame.exe!UStaticMeshComponent::CreateSceneProxy(void)  C++
    INEOS-Win64-DebugGame.exe!FScene::AddPrimitive(class UPrimitiveComponent *) C++
    INEOS-Win64-DebugGame.exe!UPrimitiveComponent::CreateRenderState_Concurrent(class FRegisterComponentContext *)  C++
    INEOS-Win64-DebugGame.exe!UStaticMeshComponent::CreateRenderState_Concurrent(class FRegisterComponentContext *) C++
    INEOS-Win64-DebugGame.exe!UActorComponent::ExecuteRegisterEvents(class FRegisterComponentContext *) C++
    INEOS-Win64-DebugGame.exe!UActorComponent::RegisterComponentWithWorld(class UWorld *,class FRegisterComponentContext *) C++
    INEOS-Win64-DebugGame.exe!loadPrimitiveGameThreadPart(CesiumGltf::Model & model, UCesiumGltfComponent * pGltf, LoadGltfResult::LoadPrimitiveResult & loadResult, const glm::mat<4,4,double,0> & cesiumToUnrealTransform, const Cesium3DTilesSelection::Tile & tile, bool createNavCollision, ACesium3DTileset * pTilesetActor) Line 3235    C++
>   INEOS-Win64-DebugGame.exe!UCesiumGltfComponent::CreateOnGameThread(CesiumGltf::Model & model, ACesium3DTileset * pTilesetActor, TUniquePtr<UCesiumGltfComponent::HalfConstructed,TDefaultDelete<UCesiumGltfComponent::HalfConstructed>> pHalfConstructed, const glm::mat<4,4,double,0> & cesiumToUnrealTransform, UMaterialInterface * pBaseMaterial, UMaterialInterface * pBaseTranslucentMaterial, UMaterialInterface * pBaseWaterMaterial, FCustomDepthParameters CustomDepthParameters, const Cesium3DTilesSelection::Tile & tile, bool createNavCollision) Line 3308   C++
    INEOS-Win64-DebugGame.exe!UnrealResourcePreparer::prepareInMainThread(Cesium3DTilesSelection::Tile & tile, void * pLoadThreadResult) Line 730   C++
    [External Code] 
    INEOS-Win64-DebugGame.exe!ACesium3DTileset::Tick(float DeltaTime) Line 2059 C++
    [External Code] 

There are a few cesium error logs just before this happens:

[2024.05.10-16.20.28:696][230]LogStreaming: Display: 0.407 ms for processing 181158 objects in RemoveUnreachableObjects(Queued=0, Async=0). Removed 0 (537->537) packages and 0 (1573->1573) public exports.
The thread 1568 has exited with code 0 (0x0).
The thread 15080 has exited with code 0 (0x0).
The thread 8276 has exited with code 0 (0x0).
The thread 23964 has exited with code 0 (0x0).
[2024.05.10-16.20.45:346][693]LogCesium: Error: [2024-05-10 17:20:45.347] [error] [TilesetJsonLoader.cpp:889] Received status code 401 for tile content https://assets.ion.cesium.com/us-east-1/asset_depot/96188/OpenStreetMap/CWT/2024-03-04/14/16583/4425.b3dm?v=17

[2024.05.10-16.20.45:358][694]LogCesium: Error: [2024-05-10 17:20:45.359] [error] [TilesetJsonLoader.cpp:889] Received status code 401 for tile content https://assets.ion.cesium.com/us-east-1/asset_depot/96188/OpenStreetMap/CWT/2024-03-04/14/16582/4425.b3dm?v=17

[2024.05.10-16.20.45:369][695]LogCesium: Error: [2024-05-10 17:20:45.370] [error] [TilesetJsonLoader.cpp:889] Received status code 401 for tile content https://assets.ion.cesium.com/us-east-1/asset_depot/96188/OpenStreetMap/CWT/2024-03-04/14/16583/4424.b3dm?v=17

The thread 13460 has exited with code 0 (0x0).
[2024.05.10-16.20.45:403][698]LogCesium: Error: [2024-05-10 17:20:45.404] [error] [TilesetJsonLoader.cpp:889] Received status code 401 for tile content https://assets.ion.cesium.com/us-east-1/asset_depot/96188/OpenStreetMap/CWT/2024-03-04/14/16582/4424.b3dm?v=17

The thread 24220 has exited with code 0 (0x0).
The thread 13784 has exited with code 0 (0x0).
The thread 24268 has exited with code 0 (0x0).
The thread 24036 has exited with code 0 (0x0).
The thread 1440 has exited with code 0 (0x0).
[2024.05.10-16.21.29:800][693]LogStreaming: Display: 0.160 ms for processing 89658 objects in RemoveUnreachableObjects(Queued=0, Async=0). Removed 0 (537->537) packages and 0 (1573->1573) public exports.
Assertion failed: CurrentBlock < FNameMaxBlocks [File:D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Private\UObject\UnrealNames.cpp] [Line: 698] 
FName overflow, allocated 1024MB of string data. FName strings are never freed and should be created sparingly. Some system might be generating too many FNames, see call stack. 
[2024.05.10-16.21.39:374][553]LogOutputDevice: Warning: 

For reference, I am using unreal engine 5.2 and Cesium v2.0.0 install visa the epic game store

csciguy8 commented 1 month ago

Very impressive to see an assertion issue after 5 hours of run time!

It does look like cesium's code is generating fairly large FNames for each primitive that's created.

Here's a case where it's 165 characters... image

My first thought is, why do we need to name these components at all? Can we leave the object FNames blank? They aren't visible in the Outliner so don't have any apparent user functionality.

Also, this looks like something a soak test could potentially catch as well. @azrogers

mcleantom commented 1 month ago

@csciguy8 When I had a quick read through the code I did think that the code at line 2981 was a probable contender for the error. In my code, the error happens even if I am not moving which I thought would mean that the same assets with the same names should be loading, which would mean that the memory used by FName would be re-used, but I dont know enough about how cesium works to know if that is true.

A quick look online it seems like you cant use a blank FName

template< class T >
FUNCTION_NON_NULL_RETURN_START
    T* NewObject(UObject* Outer, const UClass* Class, FName Name = NAME_None, EObjectFlags Flags = RF_NoFlags, UObject* Template = nullptr, bool bCopyTransientsFromClassDefaults = false, FObjectInstancingGraph* InInstanceGraph = nullptr, UPackage* ExternalPackage = nullptr)
FUNCTION_NON_NULL_RETURN_END
{
    if (Name == NAME_None)
    {
        FObjectInitializer::AssertIfInConstructor(Outer, TEXT("NewObject with empty name can't be used to create default subobjects (inside of UObject derived class constructor) as it produces inconsistent object names. Use ObjectInitializer.CreateDefaultSubobject<> instead."));
    }
csciguy8 commented 1 month ago

A quick look online it seems like you cant use a blank FName

That assertion doesn't fire if you aren't in a constructor, so thankfully not an obstacle here.

Also good news, I removed creating the FName entirely and didn't see any issues.

Create this PR for it.

Thanks for writing this up!