Godot: C# memory leak using ConcavePolygonShape (etc)

[bmadgett]

Godot version:

3.1 stable

OS/device including version:

Windows 10 64bit

Issue description:

Described in https://godotengine.org/qa/43055/c%23-memory-leaks-using-concavepolygonshape-etc. Reiterated here :

I've noticed memory leaks in my game - according to the Profiler, both Static and Dynamic memory continually increase until eventually crashing. Most of my code is in C#.

I've narrowed down at least the Dynamic leak to where I'm creating a ConcavePolygonShape and then calling SetFaces() on it with an array of vertices. If this is commented out, no Dynamic leak (although Static still climbs). Note I expect memory usage to climb whilst I'm holding onto these references and creating more Nodes, but when a Node is queue_free()-ed I'd expect associated resources like the collision shapes to be free-ed as well, and it doesn't seem they are - memory usage continues to climb and never plateaus as the number of Nodes plateaus.

I've created a small test case to illustrate. Two scripts, one C# and one GDScript, both doing exactly the same thing, which is to create a new ConcavePolygonShape and populate via SetFaces() every call to _Process(). The GDScript version has flat Static memory and Object count and zero Dynamic, the C# version has Static and Dynamic memory and Object count all continually climbing. If I comment out the SetFaces() call in the C# version, Dynamic stays zero but Static and Object count still climb. If you increase the number of vertices, the leak gets larger faster (so seems proportional to number of vertices).

ConcavePolygonShape is not a Node but is held via a Reference as I understand, so should be ref-counted and disposed automatically once all references are gone (i.e. at the end of each _Process() call as I don't hold the ref anywhere). However it seems that each ConcavePolygonShape created from C# is not being ref-counted correctly perhaps, so is never been released when no refs exist.

What's going on? I'm leaning towards a reference/leak bug in the C# godot interface stuff at the moment, but have I missed something obvious?

Edit: seems like https://github.com/godotengine/godot/pull/16927 should have fixed this issue, but has something been missed?
Also could https://godotengine.org/qa/40402/profiler-question-memory-leak-c%23 be related?

Steps to reproduce:
Run the attached project, check behavior of the GDScript script when attached to the Spatial node by looking in Monitors at Static & Dynamic memory and Object count. Then remove that script and attach the C# version and look again at Monitors.

Minimal reproduction project:

ShapeLeak.zip

[bmadgett]

Just noticed this other new issue that sounds very related to me : C# memory leak calling GetOverlappingBodies() from Area2D node

[bmadgett]

Just retested this on 3.2 alpha 3 - seems to do the same thing.

[bmadgett]

Still happening in 3.2 beta 4. Has this been looked at? I can see it's set for 3.2 milestone. I'm keen for the fix since, whilst this test case looks only a "minor" leak, in my Minecraft-alike I'm constantly creating large meshes, collision shapes etc in C#, and the leak (I think due to this issue) is thus very much faster - grows to ~1Gb over 10mins or so, which is obviously stopping any serious development on the prototype.

[Calinou]

@bmadgett Nobody seems to be working on it currently. Someone needs to step up to do it :slightly_smiling_face:

cc @neikeq

[Hromon]

I agree, I also did a voxel game with great enthusiasm, in 3 days I completely made the world and already wanted to start working on content, but I saw how my world began to eat from 60 to 450 megabytes of RAM in 5 minutes of tests with 9 chunks. I began to look for topics on the forums, found yours, realized about the problem, waited for a fix, waited a long time - abandoned

[neikeq]

This was a serious bug, sorry for ignoring it for so long.

[bmadgett]

Thanks for looking at this, I'll test the fix once I can find a Godot build including it (I don't have a build system set up here and little time at present, sorry)

[bmadgett]

Retested in 3.2 beta 5 and I'm happy to report that it appears the leak has gone, static and dynamic see regular drops in usage (presume garbage collection), keeping the max size fairly stable. Thanks!