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. about cesium-unreal

[csciguy8]

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!

[csciguy8]

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...

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]

@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."));
	}