Is it possible the snapshots are missing some objects?

Hello,

is it possible the snapshots might be consistently missing some objects (the same object, to be precise)?

The reason I’m asking is because we are tracking our game-world state/data object (when you load a new game, we store a short WeakReference to the world data object, and after returning from the game to a main menu, after manually calling GC.Collect() we check if WeakReference.IsAlive is true, and if it is, we consider it as leaking the game world data.

However, I cannot find this object anywhere in the dumps (consistently, over multiple captures, over multiple executions of the actual application).

I can only find an object of the same type, but that one should be a different object, since it has a different address (by comparing the address I get at runtime and the address in the memory profiler) and different hash codes (by calling GetHashCode() of the object memory profiler finds and the WeakReference.Target during runtime), and also they are not considered a equal by Object.ReferenceEquals.

I guess the most I could in this case is send a bug report with attached snapshot and write in the report on which address the WeakReference.Target should be located in the current dump.

(P.S. I’m hitting the same issue with ░ ▒ ▓ █ Heap Explorer - Memory Profiler, Debugger and Analyzer for Unity which leads me to believe it would likely be an error in the capturing API (or the runtime itself?), rather than in the profiler that shows the snapshot contents.)

Sent the snapshot and the address where the object should be located, but isn’t listed as an object by the profiler API; should be tracked as a Case 1115010.

(Also, using the HeapExplorer tool, which also shows raw data of the memory sections*, I was able to confirm that the object of the given type really does exist on that address. So it really is bug in the profiler or in the snapshot itself)

*) This is something what is the Unity’s memory profiler missing, and that’s kinda a shame to be honest.

Hi, thanks for reporting this issue.

Truth is that in the past this API wasn’t properly maintained. There were of course some fixes here and there but thats all. When we started work on memory profiler we right away started encountering a lot of troubles and nuances of whole capture code. Some of them were really tricky to fix and in recent months we fixed most of the one that we found. Sadly I wouldn’t be surprised if this was another one of them. You can be sure that we will look into it and fix it.

Regards showing raw data of the memory section you are right: It is shame that we don’t have it. But this don’t mean that we won’t have it in the future :] Comments like yours are important feedback for us. Thanks to it we can prioritise our work in the way that it benefit our users the most.

Got a reply from the QA that they are closing the bug report since I did not provide a repro case, but they forwarded the snapshot to you guys at least.

If you ever have a chance to check it, please tell me the result! :slight_smile:

yeah, QA was a bit quick to jump to close this. I’ve reopened it. Thank you for reporting it and supplying the snapshot :slight_smile:

2 Likes

Saw "Scripting: Fixed an issue with static members such as generic classes with their argument being an array type not being reported the memory snapshot API. ", so I was hoping this might have been our case, but nope, the capture still misses the path to the object. :frowning:

Did you have any time to look into it, by any chance? :slight_smile: