Finding JS memory leak in chrome dev tools

Question

I’m using the chrome dev tools to work out if there is a memory leak in some JS code. The memory timeline looks good with memory being reclaimed as expected.

However, the memory snapshot is confusing because it appears like there is a leak because there are entries under “Detached DOM Tree”.

Is the stuff under “Detached DOM Tree” just waiting to be garbage collected or are these real leaks?

Also does anyone know how to find out what function is holding on to a reference to a detached element?

Answer 1

Is the stuff under “Detached DOM Tree” just waiting to be garbage collected or are these real leaks?

Before taking snapshot the browser will run garbage collection and sweep all objects that are not referenced. So the heap snapshot always contain only live objects. As a consequence if a Detached DOM Tree is in the snapshot than there must be an element in the tree that is referenced from JavaScript.

Also does anyone know how to find out what function is holding on to a reference to a detached element?

There should be an element(or several of them) in the same detached DOM tree that has yellow background. Such elements are referenced from the JavaScript code. You can find out who exactly keeps reference to the element in the retainers tree.

Answer 2

Since you've added the jQuery tag, I had a sneaky suspicion as to this being a jQuery thing. A quick google brought me to this page. When using jQ's detach method, a reference to the object is still kept in memory, so that could be causing your snapshot.

Another thing could be that jQuery has a div node at hand, which is -obviously- kept in memory, but never added to the actual dom... a sort of document.createNode('div') without appending it. This, too, will show up in the memory snapshot. You can't get around this, jQuery uses it to parse strings into html elements.

So to remove some elements from memory, use the jQuery .remove() method, and your mem will be cleared instantly.cf Esailija's comment on why remove doesn't quite fit the bill here.
$('#someElem')[0].parentNode.removeChild($('#someElem')[0]); Should remove the element altogether, but might not unbind the events. Perhaps something along the lines of:

$('#someElem').detach();//to remove any event listeners
$('#someElem')[0].parentNode.removeChild($('#someElem')[0]);//remove element all together

And, again, as Esailija pointed out in his answer, make sure that you assign references to any jQuery object (var someRef= $('.someSelector');) to a global variable, as they won't be GC'ed. Just avoid globals all together, in fact.
But to answer your question briefly, and clearly: no these aren't real memory leaks, the memory should be freed on the onbeforeunload event. The jQuery object is deleted, so all references go out of scope. At least, That's what my "research" lead me to believe. Perhaps not entirely relevant, but just as a reference Here's a question on mem-leaks I posted a while back, and with it a few things I found out..