New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 907383 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Memory leak when unreferenced object holds other unreferenced object's internals?

Reported by trusktr@gmail.com, Nov 21

Issue description

UserAgent: 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
 
Components: -Blink Blink>JavaScript
We'll need a explicit reproduction test case.
Labels: Needs-Triage-M70
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.

Comment 4 Deleted

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.

Comment 6 Deleted

Comment 7 Deleted

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.
Cc: krajshree@chromium.org
Labels: Triaged-ET Needs-Feedback
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...!!
Status: WontFix (was: Unconfirmed)
Mac triage: WontFix - it sounds like this is a design behavior of the V8 gc per #5.

Sign in to add a comment