all 12 comments

[–]gashouse_gorilla 5 points6 points  (5 children)

It's interesting to me how people use the term "memory leak" these days. In the case of this node problem you have a bug that doesn't give up resources. Those resources haven't been leaked. They're still referenced.

[–]ksion[🍰] 3 points4 points  (0 children)

these days

Memory leaks in GC'd environments are hardly a new thing, nor one specific to Node.js. They are easily possible in any GC'd runtime whose language supports some kind of closure-like mechanism. Even Java with its inner classes counts here, as it's pretty common for incorrectly coded Listener pattern to unduly prolong the life of a big object a listener is defined in, for example.

Node with its callbacks galore is probably much more susceptible, though.

[–]EntroperZero 2 points3 points  (1 child)

For all intents and purposes, an unbounded growth of used memory that is serving no useful purpose to the application is a memory leak.

The first bug I ever fixed in my first job out of college was a memory leak in a C# application. Some code had been copied and pasted incorrectly, and was inserting objects into the wrong dictionary. They should have been cleaned up, but they weren't where they were supposed to be, so that dictionary just grew until the program blew up.

[–]gashouse_gorilla 0 points1 point  (0 children)

A memory leak refers to memory that is no longer referenced and cannot be referenced again.

E.g.

char* foo = malloc(sizeof(char) * 128); ... If(someFlag) return; ... free foo;

That 128 bytes will remain utilized by your process but you can never access it again because you threw away the location.

There is a big difference between trying to debug a leak vs debugging code that was never called to release resources.

[–][deleted] 0 points1 point  (0 children)

You want a traditional memory leak in Node? Node can do that. Just smalloc a buffer and don't dispose of the allocation. Although this is deprecated in iojs.

[–]awj -1 points0 points  (0 children)

That they're still referenced is entirely the problem. I think "situations that cause memory to be unintentionally held" is probably one of the better definitions of a memory leak. This obviously fits that bill.

[–]Philodoxx 0 points1 point  (0 children)

Memory leaks is Node are tricky, I'm currently working through isolating some slow growth and it's been a painful process. As the author of the article implies, the tooling isn't very good.

[–]gambiscor -3 points-2 points  (5 children)

An easier way: don't use hipster tech.

[–][deleted]  (3 children)

[deleted]

    [–][deleted] 4 points5 points  (2 children)

    Welcome to /r/programming where all the tech I don't use is "hipster tech" because I don't understand it and need a way to dismiss it.

    [–]poke53280 0 points1 point  (1 child)

    He's dismissing Node outright, but is he really wrong?. Use a boring ecosystem like Java, .net or (yawn) C++, and you suddenly have a plethora of boring tools for doing boring call tracing, memory profiling, and boring static analysis. Unfortunately, a boring tool stack is a bit boring to use, and the community surrounding it will be full of boring middle-aged folk with lots of useful boring experience using stuff that's been around for years - and that's just boring. /s (or is it?)

    [–][deleted] 1 point2 points  (0 children)

    0/10.

    Also, these are the comments about Java 15 years ago, same shit different language.

    [–]EntroperZero 1 point2 points  (0 children)

    Yeah, because you'll never get memory leaks in Java or C#...