WARNING: memory leak

[Nevermind]

I’ve just found a nasty memory leak scenario in Unity. I’ve submitted a bug, bt I’m also posting this thread as a warning to fellow developers.

Here’s what happens: suppose you have a script that references some assets - prefabs, textures, whatever. This script is attached to an object in a scene. When this scene is unloaded, assets referenced by this object are unloaded too - provided, of course, that they’re not referenced somewhere else.

BUT if you store a reference to this object somewhere in code, then assets would NOT get unloaded! The object itself is destroyed on scene change, and you can’t access it from code - any attempt to use the reference causes an exception. However, with Resource.FindObjectsOfTypeAll() method you can enumerate all assets currently loaded, and these assets from now-destroyed object would still be there.

I’ve made a simple project to test this - it’s attached to the post. In it, there are three scenes. One is starting scene, and two others contain each an object that references a texture. The only difference is that “failScene” stores a reference to the object that in turn references the texture. When you return from this scene back to starting, and try to find the texture, it’d be there, and even displayed in OnGUI!

You’d have to build an actual project to test this, because in editor the texture seems to be loaded all the time right from the start. But when I checked with Windows .exe build, there was the memory leak: texture got unloaded after visiting “okScene”, but not after visiting “failScene”.
So be wary of storing references to objects after they are destroyed: it may seem harmless, but in fact causes memory leaks!

I’ve tested it all on 3.5.6. Don’t know if it happens on Unity4 beta, but I wouldn’t be surprised if it in fact does.

Submitted bug report number for anyone who is interested is an 492524

1051849–39068–$AssetUnloadingFail.zip (293 KB)

[MihaPro]

Use code in TextureScript:

	void OnDestroy()
	{
		Instance = null;
	}

[misterkid]

Long long time ago when I used javascript. And made a tower defanse game for my phone I had memory leak problems as well.

I fixed it by doing this.

private function Desotroy():void
{
DestroyMesh();
Destroy(this.gameObject.rigidbody);
Destroy(this.gameObject.collider);
Destroy(this.gameObject);
Destroy(this);
}

private function DestroyMesh():void
{
var mesh:Mesh;
var meshFilter:MeshFilter = gameObject.GetComponent(“MeshFilter”);
mesh= meshFilter.mesh;
Destroy(mesh);
Destroy(meshFilter);
}

Mesh wouldn’t get destroyed.
I don’t think it is the same problem but I do think it is a memory leak bug

[JohnnyA]

EDIT: Looked at code.

Your code is retaining a static reference to the texture. The texture is retained because you specifically asked for it to be retained.

[Nevermind]

@JohnnyA

Your code is retaining a static reference to the texture. The texture is retained because you specifically asked for it to be retained.

No, my code is retaining a static reference to a MonoBehaviour, not texture. The MonoBehaviour does reference the texture, but it’s destroyed!

[JohnnyA]

You retain a reference to an instance of TextureScript which in turn holds a reference to the Texture. Therefore the texture is still referenced and so not destroyed. Static variables are members of the class not an instance (another name for them is class variables), they do not get destroyed when a scene is destroyed.

This is not a bug; by their very definition they last for the lifetime of the application.

It also happens that using static variables (via a singleton pattern) is a great way to store common data like game state or scores as it it can be shared between scenes.

[Nevermind]

I have a reference to TextureScript, that in turn has a reference to texture - that much is true. However, the referenced TextureScript object is destroyed on scene end; and I CANT deference it afterwards! Trying to use Instance.Texture would throw an exception saying that the object has been destroyed. I can see the logic behind retaning the reference, but then why it can’t be accessed? Even better question is - ok, suppose I want to destroy this referenced texture explicitly… how can I do that?

[JohnnyA]

TextureScript.Instance is referencable.

If you set it to null before scene end the texture is cleaned up fine. If you set it to null after the scene and either load another scene or do a Resource.UnloadUnusedAssets the texture is also cleaned up fine.

[Nevermind]

@JohnnyA

TextureScript.Instance is referencable.

Could you please show me any way to access this referenced texture after scene is unloaded? Except scanning all assets for it, as my exmple does?

[JohnnyA]

texture = TextureScript.Instance.Texture;
/*
            var textures = Resources.FindObjectsOfTypeAll( typeof( Texture2D ) );
            texture = textures.Cast<Texture2D>().FirstOrDefault( t => t.name == "texture" );
            if( texture != null )
            {
                Debug.Log( "GOTCHA!" );
                Debug.Log( "TextureScript.Instance==null is " + (TextureScript.Instance == null) );
            }
*/

Works for me.

[Wozik]

The answer is sponsored by Unity Core team:

The issue is that we never unload scripts once they are in memory. Even if a gameobject is deleted that referenced it, the script - and specially its static variables stick around unless the scriptdomain is reloaded (which can be done in the editor). This is intended behavior. The solution is to clear your static variable on unload.

[Nevermind]

@JohnnyA

Works for me.

OK, sorry, I was wrong, it does work. What I don’t understand is…

@Wozik

The answer is sponsored by Unity Core team:

WHY?! First you go to great pains to make all destroyed objects look like null’s, and throw exceptions on any access, and then you turn around and say “but actually, your script is not unloaded, it’s only kinda invalid, but not wholly…” That might be intended behaviour, but it is surely inconsistent!

To clarify, this doesn’t have anything to do with static variables. Whenever I retain a reference to a destroyed MonoBehaviour, any assets referenced by that MonoBehaviour are not unloaded, even though my reference is, or pretends to be, null.

[Kim-Riber]

Hi.

When doing a singleton manager like the one in your script:

public class TextureManagerScript : MonoBehaviour
{
    public Texture Texture;
    public static TextureManagerScript Instance;

    void Start()
    {
        Instance = this;
    }

	void OnDestroy()
	{
		Instance = null;
	}
}

It is important to clear the instance when the Singleton is destroyed.

The issue is that the MonoBehavior under the GameObject is a component with both a c++ part and a mono part.
The c+ side of the MonoBehavior is destroyed when unloaded. The c# part is not since there is still a c# reference to the MB from the static variable that lives in mono.
When accessing the MB from script later on, this can be done in 2 ways. If checking equality, this is going through c++, and since the c++ part is gone, this returns null.
If on the other hand you go directly to Instance.Texture, you will not enter c++ land, and you will get the texture that is statically referenced.

This is of course not the best solution, but we have not found a way to solve this yet.

Hope this explains a bit of what is going on under the hood.

[manny003]

OK. I’ve read the entire thread very carefully and I still don’t understand one simple thing – Isn’t the Garbage Collector supposed to prevent all of this? Isn’t it supposed to clean up all unreferenced objects?

I’m running into a app crash situation where I’m switching back and fourth between scenes where, after a while, the whole thing crashes. None of the scenes have any static objects. It does however, has two static primitives (int, float).

Currently using Unity 4.5.2f1 Standard with a Pro trial license.

Manny

[Randyanto]

@Kim Riber

Hi.

When doing a singleton manager like the one in your script:

public class TextureManagerScript : MonoBehaviour
{
    public Texture Texture;
    public static TextureManagerScript Instance;

    void Start()
    {
        Instance = this;
    }

    void OnDestroy()
    {
        Instance = null;
    }
}

It is important to clear the instance when the Singleton is destroyed.

The issue is that the MonoBehavior under the GameObject is a component with both a c++ part and a mono part.
The c+ side of the MonoBehavior is destroyed when unloaded. The c# part is not since there is still a c# reference to the MB from the static variable that lives in mono.
When accessing the MB from script later on, this can be done in 2 ways. If checking equality, this is going through c++, and since the c++ part is gone, this returns null.
If on the other hand you go directly to Instance.Texture, you will not enter c++ land, and you will get the texture that is statically referenced.

This is of course not the best solution, but we have not found a way to solve this yet.

Hope this explains a bit of what is going on under the hood.

I have tried this in Unity 4.6.
Should I add Instance.Texture = null; at the OnDestroy()?

[Randyanto]

@manny003

OK. I’ve read the entire thread very carefully and I still don’t understand one simple thing – Isn’t the Garbage Collector supposed to prevent all of this? Isn’t it supposed to clean up all unreferenced objects?

I’m running into a app crash situation where I’m switching back and fourth between scenes where, after a while, the whole thing crashes. None of the scenes have any static objects. It does however, has two static primitives (int, float).

Currently using Unity 4.5.2f1 Standard with a Pro trial license.

Manny

STATIC variables won’t be touched by the GC because STATIC variables are supposed to be there as long as the application is alive

[Jonny-Roy]

@Randyanto

STATIC variables won’t be touched by the GC because STATIC variables are supposed to be there as long as the application is alive

Agreed, this is how it should work.

It’s the same situation with any idisposable objects too. for example:

StreamReader sr = new StreamReader("TestFile.txt");
// Read the stream to a string, and write the string to the console.
String line = sr.ReadToEnd();
Console.WriteLine(line);
//This will destroy the underlying StreamReader...but the variable will still exist.
sr.Dispose();

It’s not a Unity bug, it’s how programming works. Instead of complaining about it, learn about it. In my example, the StreamReader is destroyed, but the variable still references it and so can still access it’s properties. sr will only be Garbage Collected once it goes out of scope, so as a local variable, once the method ends it goes into the Garbage Collector, if it was a static variable though, then it will only lose scope when it’s set to null or the application ends. Simple.

[Stamblew]

After 7 years from the first post of this thread, I could understand and profile my game to find out that not setting the static Singleton instance to null was causing many memory leaks. This is especially crucial in mobile devices. Thanks for all the info provided here, folks!

[PigBang_1]

You also can catch this when use actions and lambda functions.
For example:

        private static Action testAction;

        [SerializeField]
        private GameObject testField;

        private void TestFunction() { }

        protected void Awake()
        {
            // If you miss unsubscription - you has leak
            testAction += TestFunction;

            // While AnyClass use Action(with class fields) - you has leak
            AnyClass.SomeFunction(() =>
            {
                testField.SetActive(true);
            });
            // or class functions
            AnyClass.SomeFunction(TestFunction());
        }