koobas.hobune.stream
Memory leak when loading textures from file
I am at my wit's end with with out of control memory usage when loading textures from files. I am making an image slideshow which cycles through images with user input. Every time I load a new image into a texture, it increases the memory usage dramatically, and eventually causes the program to crash. I am aware that there are plenty of older questions with the same issue, however, no prior answer appears to work for me. I've tried every variation of DestroyImmediate, GC.Collect, Resources.UnloadUnusedAssets, and have even tried Application.LoadLevel to remake the scene. Even with the latter, the unused textures appear to persist in memory, and there is nothing that I can do about it. I can even do a texture.LoadImage(), then a DestroyImmediate(texture) immediately afterwards, and it still doesn't free up memory. What am I doing wrong?
void SetImage(int index)
{
DestroyImmediate(GetComponent<Renderer>().sharedMaterial.mainTexture);
string url = "C:/Images/"+index+".jpg";
byte [] binaryImageData = System.IO.File.ReadAllBytes(url);
Texture2D tex = new Texture2D(8192, 4096, TextureFormat.DXT1, false);
tex.LoadImage(binaryImageData);
GetComponent<Renderer>().sharedMaterial.mainTexture = tex;
Resources.UnloadUnusedAssets();
System.GC.Collect();
}
I don't get any memory leaks by avoiding to call new Texture2D multiple times (at least I can't see any leaks in the profiler).
Texture2D tex;
void Start()
{
tex = new Texture2D(4,4,TextureFormat.DXT1, false)
}
void SetImage(int index)
{
string url = "C:/Images/"+index+".jpg";
byte [] binaryImageData = System.IO.File.ReadAllBytes(url);
tex.LoadImage(binaryImageData);
GetComponent<Renderer>().sharedMaterial.mainTexture = tex;
}
So I was getting this in our slippy map app which loaded textures from online map services and although the textures are note classic Resources, the command Resources.UnloadUnusedAssets() seems to now clear my texture memory virtually immediately under Unity 5.6.1.
On the other hand CG.Collect() seemed to do nothing.
Hope this helps some folks. :)
I'm not sure if the profiler will catch it. After closing Unity, the memory is freed, so I guess Unity's garbage collection works properly at that point, but while the program is running, the memory usage goes up every time SetImage is called, to the point where it crashes. Even with the texture at 4x4, the effect is the same, it just takes longer.
Like you said, it's not about texture size ... it's about how often you (re-)create a Texture2D (see my answer). I used 4x4 only because at this point it doesn't matter how big the created texture is.
I have now reported a bug against this problem with a $$anonymous$$imal repro project. https://fogbugz.unity3d.com/default.asp?736374_2v8g7nrue9it8rh5
Hi, thanks for the input. Calling new Texture2D once in Start rather than instantiating a new one before each LoadImage did not change anything for me. The spike in memory usage that I was seeing was from the LoadImage call itself. Whether on an existing Texture2D, a new one, through www.LoadImageIntoTexture, or binaryImageData. I didn't find a solution and gave up on it. There's probably something else I'm doing wrong, but saschandroid's code copy pasted unchanged still has the issue for me.
I am running into this on 5.3.4f1, and like Silverfire, the workaround did not help me. I have isolated the Leak to Texture2D.LoadImage(System.IO.File.ReadAllBytes(path)) (strongly suspect it is specifically the LoadImage call, but still to confirm)
Also of note: I was not able to repro in the editor using similar code.
I can confirm that I hit this problem today, and on Android it eventually caused an out of memory crash.
As saschandroid indicated the solution was to avoid re-creating the texture every frame, and instead just call LoadImage on the previously allocated texture.
when ? what unity version fix?? i found this memory leak in Unity5.3.4f1
There is a known issue in our database about this:
http://issuetracker.unity3d.com/issues/destroying-texture2d-doesnt-free-memory
Regards,
Dan, Unity Support
