I started a project in 4.10 and I am periodically getting errors from Windows telling me that the system has run out of memory and it needs to close the Unreal. I have 16GB of ram and I am not running anything else memory intensive at any point and my project is quite small.
I turned on the memory usage viewer in the editor and kept an eye on it to see what could be affecting the memory usage. It appears to be linked to two things.
- Editing the parameters or transforms of a blueprint asset that has construction script code executing. The editor appears to accumulate objects in memory every Time such a blueprint asset is adjusted. Seemingly adding the number of components present in the blueprint each Time the asset is updated. Deleting some object in the level seems to cause the editor to remove the excess objects, but little to no memory is reclaimed.
- Having a blueprint window open at all also appears to cause memory usage to inflate.I can open a blueprint window and just watch the memory usage grow at roughly the rate of 1MB per second or two. Closing the window stops the inflation, but no memory is reclaimed. Over the course of a work session, this slow growth will eventually use up all system memory and cause Windows to close the editor.
As far as I can tell, I’ve not implemented any suspect code in my blueprint’s construction script.
I’ve created a video illustrating the situation.
Windows 10 Pro 64bit (build 10586)
Intel i7-4770K
16 GB Ram
DirectX 12
We are working with 4.9.2 version of the engine but this bug still remains in 4.10. In our case it helped when we close all open function tabs in the editor.
Thank you for your answer. However as of yet, this blueprint is the only one I have with any script, and I don’t have any functions defined in within it. Closing that blueprint window does stop the leak, but this just delays the inevitable as no memory is freed when doing so.
Hello GaryDoesThings,
I’ll be looking into the first issue shown in your video with the objects being kept with construction script. The second issue you reported however, the one with the blueprint tab, is already reported under the number UE-21203. We hope to have it fixed soon but it seems the easiest way to avoid the majority of the memory leak in the meantime is to always keep the extra tabs docked to the main editor and keep it maximized.
Thank you for reporting this issue GaryDoesThings. I’ve logged your initial issue with the construction script memory leak under the number UE-23817. As for the other issue, it has already been reported as stated in my previous comment. I hope we can have this fixed as soon as possible.
Have a nice day!
Great, thank you so much for your responses .
Hi there,
The first issue (UE-21203) was resolved in 4.11. That was most likely the source of the low memory warnings, as that appears to have been a true leak.
The second issue (UE-23817) is I think sort of a false positive rather than an actual leak. What happens by default as you drag an instance of a Blueprint Class around in the editor is, that instance is reconstructed for each position change. Thus if the Construction Script is adding components (as it is in this example), you can end up with several new objects being allocated and freed at each delta. For what it’s worth, you can disable this behavior for an individual Blueprint Class by opening it in the Blueprint Editor, clicking the “Class Settings” icon in the Toolbar, and unchecking the “Run Construction Script on Drag” option in the “Blueprint Options” section in the Details panel. This will defer any updates to the appearance (i.e. reconstruction) until after the drag is complete.
For additional reference, the memory display in UE4 is tied to the “Working Set” counter in Windows and not a specific UE4 heap allocation space. This means that even as objects are freed inside of UE4, that number may not necessarily go down (internally it includes free space that can, for example, be recycled for use again without incurring a more expensive OS page allocation). It also means that from Process Explorer’s point-of-view, UE4 process usage may remain at or near the same level even as objects are freed.
Finally, the object counter display in UE4 includes both allocated and freed objects that have not yet been garbage collected. As the garbage collector runs only periodically, this number may not immediately go down as objects are removed or deleted. You can force a garbage collection pass by opening up the console tab and typing ‘obj gc’ - this should cause the object count to drop. However, as noted above, reported memory usage may or may not necessarily be decreasing alongside it.
Hope this helps!
Yes, the main issue does appear to have been solved with 4.11. And thank you for your description of the counters.