Develop Reference

What is InternalNode in chrome heap profile

I am diagnosing a memory leak in a jQuery based single page application using the Chrome DevTools heap snapshot tool as described on https://developer.chrome.com/docs/devtools/memory-problems/#discover_detached_dom_tree_memory_leaks_with_heap_snapshots
I have solved some issues this way, but I have now hit a roadblock where I can no longer determine what is keeping an object in memory. For example, for one of the objects it returns the following retainers:
From what I can tell, the object is retained because it's used inside a closure scope of a click event.
But the click event is on a detached HtmlDivElement, which should be garbage collected.
It is somehow linked to the window object via InternalNode objects. I have searched all over the internet, but I'm unable to find what these InternalNode objects are.
My question is, what are these InternalNode objects and how I can "free" them so my objects are garbage collected.

TL;DR
Leak is caused by https://crbug.com/1177010
Clicking on an element outside the detached element prevents the memory leak from occuring.
Following #wOxxOm's comment, I have compiled a version of Chromium with the enable_additional_blink_object_names flag enabled so that it shows the names of the InternalNode objects.
It appears blink:MouseEventManager is preventing the detached dom element from being garbage collected.
This finally lead me to https://crbug.com/1177010, which I could confirm by clicking outside the detached element before taking another heap snapshot.

Can I get the GC'd memory from dev tools?

I have a large app thata I am debugging. I have noticed a saw-tooth memory pattern that indicates that there is frequent GC going on.
In an effort to debug this I am trying to find the contents of the memory that is being GC'd. Is this possible in chrome with dev tools? I know I can take heap snapshots, but how do I guarantee that this happens immediately before and after a GC? I know I can trigger a heap snapshot from code, but same question.

Insight into the garbage collection is not available yet in the DevTools. I have requested this feature some time ago though. You can "star it" to indicate that you would also like to have it.
As for the snapshots, you won't be able to use them for your purpose. Before each snapshot is made all garbage is collected.
Are "dead" (unreachable) objects included in snapshots?
No. Only reachable objects are included in snapshots. Also, taking a snapshot always starts with doing a GC.
source
Your best shot is to record heap allocations ("Profiles" > "Record Heap Allocations") and use memory snapshots to understand what objects are being created by the app. With that knowledge, you can try identifying shortly lived objects (that cause the sawtooth pattern).
BTW, if you are using requestAnimationFrame, you should know that it's causing saw tooth pattern by itself.

With Record Heap Allocation profile type you can get the information about allocated objects.
You need to enable "Record heap allocation stack traces" option in the DevTools settings.
See screenshot.
After that you need to record "Record heap allocations" snapshot type.
The recording process may significantly slow down the page because DevTools scans the js stack each time when the page allocates an object. As a result you will get the snapshot which has the information about allocations. In many cases DevTools can detect the class name of the objects. See screenshot.
In the snapshot you need to select Allocation view.
I think the information in the grid could help you to solve your problem.
In the screenshot you can see that there were 41k allocations for a class but only 12k of them still alive. So 29k objects were the garbage. And even if you don't see the name of the object you could jump into sources where the objects were allocated.

Using Chrome's heap snapshot analyzer, how do I interpret dead-ends in the retainers view

I have a single-page app that is leaking fairly substantially. I am trying to track down the memory leaks using Chrome's built-in memory profiling tools. The heap snapshot has been giving me a lot of success in tracking down quite a few problematic code blocks, but I have now reached a bit of a dead-end.
I have taken a heap snapshot and isolated a variable that has clearly leaked. I then open it up the retainers view so that I can see why the object has not been garbage collected. What I am now seeing in the retainers view (see below) is confusing me. It keeps reaching a dead-end even though it claims that the given node in the graph still has a distance of 11. I'm not sure why it won't let me dig into the object when it says that there is still depth there. I was expecting that I would be able to expand all the way to a global variable on the window object.

how can I verify a specific Javascript object will be garbage collected?

Is there any kind of assertion that I can make to verify that a particular object can be GC'ed in Javascript? The purpose is to have a unit test that asserts a memory leak is fixed.
at this point I don't know of any direct language support for this - I don't think Javascript has weak references or finalizers, which is how I probably would have done this in Java or C#.

You cannot have any javascript code that detects if a specific object can be GCed. The very code that would test it would keep it from being garbage collected because that code would, by definition, have a reference to it and the garbage collector will not GC something that still has a live reference to it.
The things you can do to verify that there is no memory leak:
Devise a test that runs the offending code over and over and measure the total memory usage of the browser to verify that the memory usage it not going up and up and up.
Assign a gigantic property value to the object (e.g. a mongo string) that is so large that you can clearly see if these objects are leaking in total memory usage.
Use various developer tools (which vary by browser) to look at the browser memory usage in finer detail.

Detect node.js/javascript memory leak in code

I have some code that is working, however it has a memory leak in it.
What are some good strategies for tracking memory leaks in node.js?
What steps should I follow when looking for such leaks?
How can I track the leak in my code?
Thanks

You can figure this out by profiling the memory usage of your application.
Javascript objects are allocated on the heap, so you'll want a tool that can dump the heap. After acquiring a heap dump you can inspect it and see how many instance of a given object (or function) exist.
E.g., for your code you know you create a socket whenever a user connects. Dumping the heap while three users are connected should show ~3 sockets. Dumping the heap after those users disconnect should show ~0 sockets.
You can actually use the Chrome heap dump analyzer with Node.js heap dumps.
Documentation on the Chrome heap dump analyzer: https://developers.google.com/chrome-developer-tools/docs/heap-profiling
Project that allows you to take Node.js heap dumps and inspect them in chrome: https://github.com/bnoordhuis/node-heapdump
Just fyi, functions are going to show up in the heap dump under the (closure) section.
You'll want to make sure you name your functions (even if they don't need a name) so they show up as something useful in the heap dump.
For example, something like
function() {
}
will just show up as function() in the heap dump. Where as:
function taggedFunction() {
}
will show up as function taggedFunction() in the heap dump. If you create 100 taggedFunctions then you'll see taggeFunction in the heap dump 100 times. Basically, naming your functions lets you figure out if you keep creating and leaking them.