Memory leaks can be hard to track down.
After weeks of effort, a team mate finally figured out that a default noop function param, eg function blah( param = () => {} ), was never being gc’d. Wut?!
After weeks of effort, a team mate finally figured out that a default noop function param, eg function blah( param = () => {} ), was never being gc’d. Wut?!
But yes, in general tracking down leaks in JS is a huge pain...
There are some browser-specific tools that will do something like that out-of-band (e.g. in Firefox about:memory has a "Save GC & CC logs" option that outputs data about what the GC and cycle collector heap graphs look like). But interpreting those graphs is not easy, sadly.
More information about the technique can be found in a PLDI paper (which I presented last week :D ), which I tried to write clearly so that it is accessible to a technical audience (i.e., non-academics) [1].
[0] http://bleak-detector.org/
[1] https://dl.acm.org/citation.cfm?doid=3192366.3192376 (shouldn't be paywalled, but if it is, it's also available at [0])