Unknown Mono memory leak

I have a Mono memory leak (and it's pretty big), to the point where you can comfortably reach 5GB of RAM in 10 minutes and it just keeps on going

Within the Profiler, only the 'Mono' number increases, and Memory Profiler doesn't record this memory leak (it just stays at about 900MBs).

This leak is present in the Editor and in Standalone PC.

My game is a voxel game and the leak only seems to occur when loading new chunks.

All the meshes share the same Texture2D using MeshRender.sharedMaterial.
All Chunks are pooled.
All Lists used for creating the Chunk's mesh (vertices, triangles, uvs) are reused using List.Clear().
Blocks are stored in jagged arrays within the Chunk.
Async-await and Task.Run() is used pretty heavily for multithreaded chunk generation/loading.

Unity 2019.4.5
IL2CPP
URP

Does anyone have any idea what may cause such a large memory leak or how I can check what it is as Unity isn't telling me where it's coming from. Thank you.

 

If you're instantiating textures at runtime, are you Destroy()ing them when they're no longer needed?

Maybe post your chunk loading code.

 

Two textures are currently being created at runtime, which are used as a base and metallic map for a material which is also created at runtime.

These textures and materials are only created once, on startup. So I don’t see how this in itself will create the memory leak.

All chunks then share this material.

I may post my code tomorrow, but I’m not sure if anybody will bother reading it. It’s pretty long. 2240 lines.

 

Sounds like a reasonable way of doing it. And yeah ... 2240 lines is quite long ... maybe you could try commenting out some of your code, figuring out which part causes the leak and then posting it here But at that stage you'll probably have figured out the problem yourself anyways.

Could it be that you have some async tasks that never complete and so you end up with millions of them?

 

Am having same issue. 3Gb after SD Maid and Device Care

 

Both are increasing.

Within the Memory Profiler in Tree Map, the only noticeable differences are that with the originally loaded 230 chunks
there are:
146.3MB (787) allocated to Vector3[]
333.6MB (542) for Mesh
total of 750MB for Mono.

After travelling some distance and loading/unloading chunks, with loaded 245 chunks:
186.2MB (787) allocated to Vector3[]
291.5MB (542) for Mesh
total of 2400MB for Mono.

I'm not entirely sure what I'm looking for when it comes to the Memory Map.
I have a good amount of blocks that look like this, just with slightly different names:
As well as one very large but empty one with 1.5GB called ALLOC_GFX_MAIN.

Some of them near the top are a lot more green. Most of them have no objects in the Objects list.
Examples:






Then there's many blue regions that are all very similar. A lot of Vector3[] and Vector2[] averaging at 400KB each, with the ChunkData classes (72B, contains a 3D jagged array of BlockData (ushort and byte)). ChunkDatas are not pooled, maybe they should?



Deep profiling with the Profiler doesn't work. The Editor basically freezes on the first chunk and after waiting five minutes, it's still frozen.

 

When looking at all objects:
Before:


After:

 

Yeah, I've been doing some of that.
I made some changes for testing purposes. When a 'Region' (16x16 Chunks) is unloaded, I removed it from a certain 'transition period' and decided to instantly destroy it using 'DestroyImmediate'.

It appears one cause of the memory leak was that pooled Chunks (that weren't actively used) were still referencing their previous Region (which was supposed to be destroyed), and ChunkData (contains info about the blocks and such). Not entirely sure how this led to such a large leak unless a RegionData (which has the references to all 16x16 ChunkDatas) was caught between it all.

With the current design of my game, there's pretty much always surplus pooled Chunks, about 5-10. I guess these surplus Chunks were still referencing old data.

Although the Memory Profiler does reference these RegionDatas and ChunkDatas that were being referenced by some pooled Chunks, it didn't really show their actual size. It appears that the Memory Profiler was not picking up the 3D jagged arrays that contained the blocks (which would have contained quite a bit of data).
Evidence:



After quite a bit of testing, my Mono usage is usually in the range of 1.8-4GB, instead of a constant (virtually never-ending) increase (with some rare random decreases).

FYI, I only just found the References button for the Memory Profiler - very useful.

I was thinking that could have led somewhere, as with my current code it does seem like that could happen if I was to unload a Chunk before it actually finished generating, but I didn't notice anything.[/QUOTE]

 

Well, there's no reference to any Block array in the Memory Profiler, even though there are over 193 Chunks currently active.




My code doesn't clear the array. But even if it did, wouldn't 'ChunkData' still at least show the field for it? Just with a null value or something?


Saving the active Chunks produces a save file which contains the data in the Block[][][], so wouldn't that mean it's still in memory?

 

I assume this would be the Issue ID: 1266540