Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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 opened this issue May 14, 2024 · 3 comments · Fixed by #1423
Closed

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

mcleantom opened this issue May 14, 2024 · 3 comments · Fixed by #1423

Comments

@mcleantom
Copy link

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
Copy link
Contributor

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
Copy link
Author

@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 csciguy8 mentioned this issue May 14, 2024
Merged
@csciguy8
Copy link
Contributor

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix FName memory issue when running for extended periods of time CesiumGS/cesium-unreal
2 participants
@mcleantom @csciguy8