Empty texture line in memory profiler after a destroy : Leak ?

Unity Engine
1

Hello all !

Here’s the situation :

  • I create a texture with a image downloaded from internet (with flags set to HideAndDontSave but i don’t change my problems with or without)
  • I use the texture somewhere and keep the reference of the texture in a manager
  • I clearly see the line of the used texture when I do a memory snapshot in the profiler
  • When I don’t need it anymore, I destroy the Texture (with Destroy(Texture2D)) and lose the reference.

What I except :

  • The line in the memory snapshot of the profiler disappear

What I got :

  • The line lose its name and the reference count is none, but there’s still a blank line and it takes memory.
  • If I repeat the download/destroy scneario multiple times, multiple blank line is added to the profiler, resulting of a memory leak.

935×399 19.5 KB

Question :

  • What do I forget in the create/destroy process regarding texture management ?
  • Some told me to use Resources.UnloadUnusedAssets but 1) it’s not a load from Resources, and 2) it does nothing from what i’ve tested
  • If nothing : Is this editor related (the editor keeps the reference of the loaded texture for some reason) ?

Thanks a lot !

2

Bumping just once and i’m out.

No one has this problem ? :frowning:

3

After destroying the texture, are you nulling all references to it? Unity’s fake null might be at fault here. Also, have you tried profiling this with the Memory Profiler package? And does this also happen when you profile a built player?

4

Hm I can’t be sure I null of references, so let’s suppose it’s not the case. Unity’s “fake null” just do these memory footprints in Editor, but does it does the same in build ? If it’s just an editor thing, I can let the case here.

I wasn’t aware of the Memory Profiler package, i will download it and check that for sure !

1 Like
5

I’m also experiencing this issue, and recreated it in a new project (download here: https://drive.google.com/file/d/1LiQbmvxzwU6ZaXvideJTHquRPtcxp9ML/view?usp=sharing)

Steps to reproduce:
Play the game, and take memory snapshot using Memory Profiler. Should have a single large texture file from Scene 1, as shown in “1” attached.

Click the “Transition to new scene” button, and take another memory snapshot. An empty Texture2D entry has appeared. Shown in “2” attached.

With larger projects, multiple empty Texture2D memory slots seem to appear. Unsure if this happens with built projects as Memory Profiler always crashes when I try and take a snapshot of builds.

Any ideas?

6290570--695714--1.png
6290570--695714--1.png1155×597 121 KB

6290570--695717--2.png
6290570--695717--2.png1141×564 128 KB

6

That crash was a regression in the serialization layer of the snapshots. It is fixed in 2019.4.10f1 and as part of a RCA, we added tests to ensure we’ll not break the serialization layer again. Please excuse that slip up of ours.

I’ve just tried to reproduce this in 2019.4.10f1 with the project you provided on a Windows Standalone build and there are no unnamed textures in when memory snapshotting the second scene. Then I’ve taken another look at the snapshots provided with your project above. If you follow the references to that 18.8MB unnamed Texture2D object, you’ll find that it is being referenced by the Memory Profiler itself. So basically, it’s the preview image for the snapshot you just took.

There are some other unnamed textures in that snapshot without any references to them so it’s a bit trickier to figure out where those came from without knowing more about the circumstances of how you took these snapshots but I’d assume they are likely from some part of the Editor (possibly even the Memory Profiler) and therefore not relevant in a build.

Note that Texture2D objects that are created on the fly from your code (or in this case the Memory Profiler) will just not have a name by default if they are not associated with an asset. We’ll improve this in the Memory Profiler logic and give the textures used in it some meaningful names to avoid further confusion around this though, so thank you for raising this :slight_smile:

Another, mildly embarrassing side-note on this: while checking this out we realized we were actually leaking these preview images as well as the texture used by the memory map :sweat_smile:. Sooo… fixing that as well while we’re at it. Look out for a new package version to drop in the next week or so. Thanks again for stubbing our nose at it.

I guess this just became relevant again:
6302399--697649--YoDawgMemoryProfiling.jpg
And yes, I guess we should be doing this more often…

Ehem… Anyways: besides Editor tooling slipping up like this, I’d generally be vary if you encounter something that looks like weird memory behavior and stuff not getting properly unloaded from memory when profiling Playmode. There’s all kinds of ways that the Editor behavior can influence what gets unloaded when, therefore, as long as we hopefully kept snapshotting of built players in a working state, I’d investigate this behavior in a built Player instead of in the Editor.

Only use the memory profiler in the editor for quick checks while iterating on issues found in built players, then verify your changes on a built player again and stay vary while profiling in the editor:

  • sizes might be off due to platform specific behavior or Editor quirks
  • memory might not get unloaded because it is still used by the sprite atlas builder, an inspector preview or something else entirely
  • and, hopefully less often, the editor tools might throw in some leaked resources to keep things interesting…
7

FYI, the fix for this has just landed with the release of com.unity.memoryprofiler@0.2.6-preview.1 .
If you create any Texture2D objects without naming them, they will still appear without name in the snapshot though.