do you have any tools to help finding / solving the problem of Memory Leak of Chrome Extension? [duplicate]

Those elements are being referenced in your code but they are disconnected from the page's main DOM tree.

Simple example:

var a = document.createElement("div");

a references a disconnected element now, it cannot be GC'd when a is still in scope.

If the detached dom trees persist in memory then you are keeping references to them. It is somewhat easy with jQuery to do this, just save a reference to a traversed result and keep that around. For example:

var parents = $("span").parent("div");
$("span").remove();

Now the spans are referenced even though it doesn't appear you are referencing them anyhow. parents indirectly keeps references to all the spans through the jQuery .prevObject property. So doing parents.prevObject would give the object that references all the spans.

See example here http://jsfiddle.net/C5xCR/6/. Even though it doesn't directly appear that the spans would be referenced, they are in fact referenced by the parents global variable and you can see the 1000 spans in the Detached DOM tree never go away.

Now here's the same jsfiddle but with:

delete parents.prevObject

And you can see the spans are no longer in the detached dom tree, or anywhere for that matter. http://jsfiddle.net/C5xCR/7/

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.

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..