Memory leak when unreferenced object holds other unreferenced object's internals?
Reported by
trusktr@gmail.com,
Nov 21
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Steps to reproduce the problem: I have an object (call it 'foo') that contains another object (call it 'bar'), where bar is an instance of the simple Three.js EventDispatcher class (https://github.com/mrdoob/three.js/blob/dev/src/core/EventDispatcher.js). The `foo` object creates a function (call it `handler`) and passes it to `bar` by calling `bar.addEventListener('some-name', handler)` and at that point `handler` gets stored inside of the `EventDispatcher#_listeners` property of `bar`. When there are no references to both `foo` and `bar`, and I have not called `bar.removeEventListener('some-name', handler)` to remove the handler, both `foo` and `bar` remain in memory and are not garbage collected, although they are unreachable! What is the expected behavior? I expected `foo` and `bar` to both be collected. What went wrong? But apparently they will not be collected. Did this work before? N/A Chrome version: 70.0.3538.102 Channel: n/a OS Version: OS X 10.14.1 Flash Version: If I do change my code to call `bar.removeEventListener('some-name', handler)`, then both `foo` and `bar` will be collected. My expectation is that although `foo` and `bar` are linked together because the handler contained by `foo` is held inside of `bar`, that they both (and the handler) should be collected. I'd love to make an reproduction, but I'm overloaded with my daily job and personal stuff and the code base I'm working is private and large. More details in the following Three.js GitHub issue: https://github.com/mrdoob/three.js/pull/15292
,
Nov 21
,
Nov 21
I can't reproduce it with a simple example, so maybe there's something leaking outside of the two objects I describe that causes my `foo` and `bar` example to leak. (my actual case is fairly big). Can you please just close this issue, and if I in fact discover something with a repro, then I can make a new one? I'd rather not distract until when/if I have a reproduction.
,
Nov 21
It seems like what I'm experiencing may be in fact the following issue, which is "by design", but may be biting me: https://bugs.chromium.org/p/chromium/issues/detail?id=315190 Maybe I think "I'm done using objects" but they stick around because of that? That would explain the behavior I'm seeing, but I haven't confirmed it.
,
Nov 21
My actual case is in a large application, so the complexity is much higher, but in my case simply removing the references between the two objects (like I described) causes a huge amount of leaking to go away. I'm not sure what to check for. I'm scouring a huge number of Objects in the Memory tab, but it's not completely human-readable. A nice visual node graph would help. --- The documentation on the Memory tab Heap Snapshot feature is sparse at best. F.e. what does a grayed out item mean? etc. The docs over at https://developers.google.com/web/tools/chrome-devtools/memory-problems/heap-snapshots don't go too far in depth, and appear to be outdated.
,
Nov 23
trusktr@ - Thanks for filing the issue...!! Could you please provide a sample test file/url to test the issue from TE-end. This will help us in triaging the issue further. Thanks...!!
,
Jan 2
Mac triage: WontFix - it sounds like this is a design behavior of the V8 gc per #5. |
||||
►
Sign in to add a comment |
||||
Comment 1 by dtapu...@chromium.org
, Nov 21