I've always felt like "memory leak" wasn't the proper term for GC'ed languages.<p>If you forget to free a malloc'ed buffer, yeah, you're leaking memory.<p>Here, in the example given, well, the developer would be doing something stupid (i.e. keep track of something created at each request in a global variable). This isn't a leak per se.<p>I mean, it's not a memory management bug you can fix: it's a behavior that's inherently not sustainable and that will need to be changed.
A "leak" we found as this:<p>Our code parsed a large HTML-like string read from a file and extracted a small portion. Then we created an array with those extracted strings (many files). The original large HTML-like string was no longer needed.<p>The problem: The (V8) runtime never created a new (very small) string and copied the section. Instead, it kept the huge strings around. So while we needed only 64 bytes from many kBytes of a string, we ended up keeping the kBytes anyway. Since those were pretty big arrays we ended up with a <i>huge</i> amount of wasted memory.<p>We ended up with a hack-function to do a substring creation that forced V8 to create a new string, by using string addition, preventing V8 from "optimizing" and using a pointer into the existing string (code shown is only the core part of that function):<p><pre><code> s.substr(start, length - 1) + s.charAt(start + length - 1);
</code></pre>
This was a process size difference of hundreds of megabytes, since we read a lot of files and extracted a lot of values. Array(100000) of 64 byte strings vs. Array(100000) of many kBytes of strings, just to give an idea of the possible magnitude. The more long strings you extract small values from the more of a problem you get.<p>This also could be a response to @Ecco. This leak is caused by internal runtime behavior. There actually is an open issue for this, has been open for quite some time. I don't understand it, this only isn't a huge problem because not many people have code that extracts tiny parts from lots of strings and then keeps references to those tiny strings around. But that's legit code, and anyone who does runs into this problem, and it is not a problem of the JS code. Maybe the optimization should force a copy if the large string could be GCed, but sure, that's quite a bit of work. Still, the current state of simply keeping references to the original string for all substrings seems problematic to me.<p>The issue is this one I think (I only just googled quickly): <a href="https://bugs.chromium.org/p/v8/issues/detail?id=2869" rel="nofollow">https://bugs.chromium.org/p/v8/issues/detail?id=2869</a><p>Somebody's blog post: <a href="https://rpbouman.blogspot.com/2018/03/a-tale-of-javascript-memory-leak.html" rel="nofollow">https://rpbouman.blogspot.com/2018/03/a-tale-of-javascript-m...</a>
A few years ago we had a nightmarish resource leak in our server. The code in question was reading and parsing HTML, looking for a handful of specific tags (title, description, etc). Under heavy load the server would be stable for a few hours, then memory would suddenly explode and kill the NodeJS process.<p>The problem was caused by the HTML parser we were using. The parsing results appeared to be a POJO but apparently there was much lurking under the surface.<p>The fix: `parseResults = JSON.parse(JSON.stringify(parsedResults))`
I've found this to be rarely as simple as the post makes it out to be. It might not be in one place, you might not know what to look for exactly and there is no way of knowing where the actual leak is coming from. You just know that some array or object is large. Also, instead of installing packages, you can achieve the same with the chrome dev-tools and running your process with --inspect.
Now I'd like to hear if anyone has any tips on how to go from the "Alloc. Size" sorted heap dump where you can clearly see a huge array of waste, to the actual location/initialisation point of the array in your code base. Trivial when you have one file and two external libraries, maybe not so trivial when you have hundreds of files and hundreds of libraries.
Memory leaks are not the only kind of leak I had to deal with in my career. I think one the worst I have stumbled upon is a network connexion leak in a database connexion pool.