We are using Unreal 5.3.1 and Cesium 2.7.0, and we have encountered an FName overflow in builds which causes the build to crash every time. This issue consistently occurs after running the build for 12 hours +. Due to the special use case of our project, we would prefer the build to be able to run for at least 48 hours without crashing. It would be greatly appreciated if anyone has an idea of how to fix this.
Thank you!
> [2024.07.15-22.49.07:842][560]LogWindows: Windows GetLastError: The operation completed successfully. (0)
> [2024.07.15-22.50.07:862][560]LogWindows: Error: === Critical error: ===
> [2024.07.15-22.50.07:862][560]LogWindows: Error:
> [2024.07.15-22.50.07:862][560]LogWindows: Error: Assertion failed: CurrentBlock < FNameMaxBlocks [File:D:\build\++UE5\Sync\Engine\Source\Runtime\Core\Private\UObject\UnrealNames.cpp] [Line: 684]
> [2024.07.15-22.50.07:862][560]LogWindows: Error: 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.07.15-22.50.07:862][560]LogWindows: Error:
> [2024.07.15-22.50.07:862][560]LogWindows: Error:
> [2024.07.15-22.50.07:862][560]LogWindows: Error:
> [2024.07.15-22.50.08:080][560]LogExit: Executing StaticShutdownAfterError
> [2024.07.15-22.50.08:152][560]LogWindows: FPlatformMisc::RequestExit(1, LaunchWindowsStartup.ExceptionHandler)
> [2024.07.15-22.50.08:152][560]LogWindows: FPlatformMisc::RequestExitWithStatus(1, 3, LaunchWindowsStartup.ExceptionHandler)
> [2024.07.15-22.50.08:152][560]LogCore: Engine exit requested (reason: Win RequestExit)
Hi @Brian_Langevin, Thank you for your reply. I donāt have the stack trace for it right now, but I can confirm Iām using the Cesium map and Cesium geofence. Here are some details on how I am using it in the project:
Iām using the Cesium terrain in the level and CesiumGeoreference. In my C++ code, Iām calling the function CesiumGeoreference->SetOriginLongitudeLatitudeHeight(CoordinateToSet); to set the coordinate on tick. Right now, the build crashes after it runs for around 12 hours.
Let me know if this is helpful and if there is anything else I can provide you. Thank you for your help!
Apologies for the delayed follow-up on this, and thanks for the information thus far. Iām trying to follow the history of this ticket ā it looks like youāre running out of memory due to FName memory? As Brian mentioned, we did release a PR to prevent tiles from creating numerous FName objects, so Iām not sure what else could be contributing to that issue.
It would help to know two things:
Are you still experiencing this error on the latest version of the plugin? (v2.7.1)
Are there any other objects in your level that are being created / destroyed at runtime?
Hi @janine , Thank you so much for following up. Here is some updates and things we tried over the last week:
I tried followed the link Brian gave me. I checked the code of CesiumGltfComponent.cpp on my end. I saw in the PR the developer remove āmeshNameā at multiple location in CesiumGltfComponent.cpp , but in mine CesiumGltfComponent.cpp āmeshNameā was replaced be"componentName". So I tried to remove all reference to ācomponentNameā and made a build yesterday.
This time instead of getting the FName overflow error, the build crashed after running for 5 hrs with this error
We are not sure if us modifying the CesiumGltfComponent.cpp is the right move, itās just something we tried to avoid the FName bug.
And to answer your question:
we were on v2.7.0, I update it to 2.7.1 today and I can run a test with the update as well
we do have other game objects being created and destroyed, but that doesnāt happens often and mostly happens in the first 10 min when we fired up the build. So I donāt think they will be causing the crash after the build running for a long time
Thank you so much for your help. Looking forward to your reply
We suspect it may have to do with the materials. Especially this line:
Weāre creating a unique FName for every material instance in Cesium for Unreal. However, this actually seems necessary. In Unrealās MaterialDynamicInstance.cpp file, it contains this line:
// If a MID is made with the same name and outer as another, it will overwrite it. To avoid this we will change the name when there is a collision.
Name = MakeUniqueObjectName(Outer, UMaterialInstanceDynamic::StaticClass(), Name);
So itās not as simple as spawning all of the materials with the same name. I think the true solution for this would be to create a pool of UMaterialInstanceDynamic instances, and to reuse existing ones when tiles load in / out.
Iāve created an issue on Github here to track this. Weāll be sure to post updates to this thread when there is progress. Thank you!
Thank you for looking into this. This is really helpful, Iām looking forward to see more progress on this!
Something we would like to ask is that, if FName ImportedSlotName is just a constant, will that fix the problem? or will it keep overwriting the old material? Cause we are thinking if itās just gonna overwrite the old material, we are fine with it if that will solve the FName overflow problem. Thank you in advance.
Something we would like to ask is that, if FName ImportedSlotName is just a constant, will that fix the problem? or will it keep overwriting the old material?
From what I can tell, the materials all require different names so theyāre distinguishable to the renderer. If you use the same name, it will overwrite the existing material.
We have to use a material instance per-tile because every model contains its own textures, parameters, etc. So using the same material instance for every tile will likely render the tileset incorrectly. But if you try this out and experience different results, let us know!
But if you try this out and experience different results, let us know!