Are there any known memory leaks in unity3d or mono?

Is there any mono or unity3d api call or language construct to be avoided to prevent memory leaks?

I am not talking about programming errors from us, unity3d users, like keeping references to lots of data thus preventing the garbage collection to work.

I mean the kind of stuff that is legal and should work just fine but due to known implementation bugs we must avoid.

there are not such api known but there are practices that you can do to make garbage collection faster and better.

  1. don't allocate memory (specially for large objects) in functions like Update because this will cause multiple allocation and deallocation.
  2. unity/mono's garbage collector is not an advanced one like what you have in .NET or java. it don't use generation based collection and different heap parts for different size objects. i don't know how much it improved for mono 2.6 but it not as good as .NET's GC.
  3. use GC.Collect() whenever you think you have time and allocated many objects that you don't use any more. why you should wait for the garbage collector.
  4. if you use unmanaged (native) plugins try to implement appropreate interfaces to unload resources properly.

memory for objects like meshes and textures will not be collected when you call GC.Collect(0); because they are not managed data and the managed apis just create them in unmanaged memory for you. if you want to know more about memory leaks that unity had before and solved. take a look at this page. i think there was not any. the mono version is too old but in 3.0 we will have mono 2.6 wich is a big improvement.

I have found unity memory leaks. One seems to be any creation of Texture2D objects. I worked around this by only creating them once, and using Resize() and SetPixels() after that.

I am also seeing memory that's never reclaimed in a function that modifies a large Color[] array, looping over it and manipulates each of values before it is set as the pixels of a Texture2D object (persistent).

I made a testcase and filed a bug today--in our actual game, the memory grows without bound. In the testcase, the Unity editor's memory grows without bound, but the standalone build gets to 435M and does not increase beyond that. Changing scenes definitely does not free the memory, because that is part of the test. The problem is more serious when the work is done in a separate thread.

UPDATE: The problem occurs whenever a temporary thread accesses non-static data members or functions. When this happens, all of the class's memory fails to be released when the class is unloaded in a scene change.