Heap Snapshot Contains unreachable Objects
Reported by
stefan.p...@gmail.com,
Oct 11 2017
|
|||||||||
Issue descriptionChrome Version : 63.0.3236.0 (Official Build) canary (64-bit) (but I have been seeing this issue for at-least the last year) Performing a Heap Snapshot commonly produces a dump which appears to contain unreachable objects. Specifically, nodes which have no path to the root. (screen shot attached). Unfortunately I have not been able to come up with a reduce reproduction. When inspecting the dump programmatically (using https://github.com/stefanpenner/heapsnapshot) it also confirms that the dump has unreachable nodes. Which suggests something has gone sideways. From a users perspective, it is unclear if: * these are real leaks, but the snapshotting missed an edge (and is thus non actionable) * these are not real leaks, but some "ghost" the heapdump snapshot. What is the expected result? I would expect all objects (nodes) which show up in the heapsnapshot to have a clear path to root. So that debugging and identifying memory leaks is possible. What happens instead? Objects are presented, which have no path to the root. And it is unclear if the issue is in the users app, or in the browser.
,
Oct 11 2017
,
Oct 11 2017
,
Oct 11 2017
,
Oct 12 2017
What does the retaining path for the object show? Can you share the snapshot? The object could be retained through an event listener which we unable to link down to the root.
,
Oct 12 2017
,
Oct 13 2017
(Please still provide feedback.) It should show a global handle as root, no?
,
Oct 13 2017
(more internals) Thinking a bit further this might be related to the fact that the global handles used for wrapper tracing are weak handles. I guess there's some filtering going on for weak handles which could be the reason why they are not showing up.
,
Oct 19 2017
I have a reproduction of the issue https://cdn.rawgit.com/krisselden/7e9e0841412a7fe2bd04dd133c41f62c/raw/8914de4bc9f2dc1cf97c00a54776a358f8b51c46/index.html After you hit the create button, the dev tools will not show you how LargeObject is retained. It is retained by SomeKey.
,
Oct 19 2017
Also, the issue should be updated, because the objects shown as unreachable are actually reachable. This makes it very difficult to find a memory leak in a large app that uses WeakMap.
,
Oct 20 2017
The problem here is that both keys and values are treated as weak by heap profiler thus not shown as retainers.
,
Oct 20 2017
This is related to issue 749502 where the heap snapshot does not handle ephemerons properly.
,
Feb 13 2018
I am looking into WeakMap retaining path issue.
,
Mar 1 2018
hey @ulan, just checking in. Curious if you have had a chance to look into ^
,
Mar 1 2018
Hi Stefan. This should be fixed with issue 749502 . I just checked the repro from comment #9 and it has two retaining paths as expected: one via the key and one via the weak map.
,
Mar 1 2018
Closing the issue. Please let me know if see any other example with unreachable objects.
,
Mar 1 2018
This is improved! Unfortunately, I do still find the output not super actionable. (it is though possible I am merely just misunderstanding something, so feel free to correct me). I have attached a screenshot, which I think illustrates my concern. Those concerns are: * foo is retained by a WeakMap (but which WeakMap?) * foo is being retained by some Bar instance (but which instance of bar?)
,
Mar 1 2018
Stefan, that looks like a different bug related to global scope. I filed https://bugs.chromium.org/p/chromium/issues/detail?id=817954
,
Mar 1 2018
@ulan, thanks you are right. When I move the vars off the global scope, stuff feel much more actionable. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by stefan.p...@gmail.com
, Oct 11 2017