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

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?

 

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

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 . 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:

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...

 

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.