Need some help understanding data

Hi there,

That first screenshot is showing a Material that was used in a scene that has been unloaded I guess? Provided there are no other things holding any references to that material, which is what the 2nd screenshot suggests as well, I guess you just didn't trigger Resources.UnloadUnusedAssets() (Unity's Asset-GC) yet, either directly or through a destructive (i.e. non-additive, non-async or with UnloadSceneOptions.UnloadAllEmbeddedSceneObjects) scene (un)load.

Unity retains assets in memory after a scene has been unloaded until the next destructive load action triggers Resources.UnloadUnusedAssets (or you do so manually), since there is a high likelihood that parts of these assets are used in the next scene as well and unnecessarily un- and reloading them would be quite wasteful.

Regarding that GameObject from screenshot 2 and 3:
Screenshot 2 shows the Native Object of the GameObject. There is 1 reference to it and as you can see in screenshot 3, that reference is coming from the Managed Wrapper object (i.e. the thing your c# scripts can use to interface with it and hold a (kinda weak) reference to it ("kinda weak reference" because you could call Destroy on it and end up with just the managed wrapper).

Now, the two things you can see when unfolding that wrapper is the field data held by that wrapper. As you can see, there isn't much to it, only a cached IntPtr to the native object (in screenshot 2) and a static offset for the instance id. Now, you're half way right that that m_CachedPtr is technically what really holds the reference to the Native Object but the Memory profiler knows about the relationship between the Managed and Native objects and has attributed the reference to the Managed object that has holds that field for you.

Now why does it suddenly say RefCount 2?
The Managed Object itself has 2 references to it specifically. Since Unity will only ever give you one and the same (i.e. cached) Managed wrapper per Native Object, no matter how often you request a reference to that Native Object, you'll actually be getting a reference to the Managed wrapper instead. So there are two Managed things that are holding on to that GO and you can see those by clicking on the ref count again.

I hope that helps to understand it? Please don't hesitate if anything was left unclear. I'm writing up a full on guide on this all and any such questions and feedback will help in making it better

That all said, we know that this hunting down the reference one level at a time is tedious and confusing in the current UI and are actively and currently working on an improved way to display these chains of references, all the way down to their roots (i.e. where this chain is "anchored" to keep it all from being GarbageCollected, wether that's the Asset- or the Scripting-GC)

 

Yeap, other roots include e.g.:

• A static field referencing stuff.
• A managed object that someone called UnsafeUtility.PinGCObjectAndGetAddress on, pinning it down as a root. Unless you released it again, obviously.
• Some Manager objects in native Unity code can be roots.
• ...

Not necessarily a complete list, but I will compile one for that guide.

Re 2. Could you list out the order of events here? It should be:

1. Scene is fully unloaded (not still asynchronously unloading), ideally destructively / with that option
2. GC.Collect *
3. GC.WaitForPendingFinalizers *
4. Resources.UnloadUnusedAssets

* Steps 2-3 are something to test, but that could be included in Unload unused assets (away from my PC so I can't check in the source code just now)

Re point 3, there are managed "leaks" which are more like "whoops, forgot a reference/pin/static root somewhere so now it's still around even though it shouldn't be" the GC still knows where it is, it just can't do anything about it until you clean up what is keeping it. Native leaks can occured if you forgot to call delete on something you malloced before (in C/C++ code).

Leaked Native Objects without a ref, that aren't getting collected by the Asset GC shouldn't really happen (not sure why I wrote that... Should correct that and also put that into the guide). So please check the order of events again.

If that persists, it's likely either a bug in the engine or a bug (or oversight) in the Memory snapshot backend, Or, most likely scenario, a bug in the Memory Profiler package's crawler... Would be awesome if you could file a bug report, for starters we should only need a snapshot file to check the most likely scenario, but if it's one of the other two, we'd need a repro project then.

If you file a bug report, please ping me the issue ID once you got the email reply with it, so I can take it from there

 

I strongly suspect that this was the issue and that async unloading might be fine as long as it happens with UnloadAllEmbeddedSceneObjects and if you wait until it's actually done.

 

Ah no, I meant SceneManager.LoadScene, but I could see how that might not fit your scenario. Still, would be interesting to see if adding 2 different empty scenes to the build and loading first the one, then the other, then taking a snapshot. At that point the GameObject should definitely be gone... If not, you got some uncleared references that the Memory Profiler is missing to capture or crawl correctly

 

Uh, yeah, that'd be a bug in the crawler. Can you please file a bug report with that snapshot and ping me with the issue ID?

 

I mean, one is a material and the other a GameObject but I'm guessing the one is using the other and should therefore have a reference to it? Just going by the name here