Receiving UDP packets retains memory

[quirkey]

We recently tried to upgrade our node statsd instances to v0.6.6 (from v0.4.12) and quickly noticed that the process was growing indefinitely once it started receiving packets. We reverted and I've spent some time trying to track it down in the code. Eventually I narrowed it down to this simplified test case:

https://gist.github.com/5a83080df20211e8ff74

Even without doing anything with the received messages, 0.6.6 quickly grows in memory per-packet received. The real kicker is it doesnt release this memory even after a long period of 0 sent. This was not a problem in 0.4.

I've tested this on centos 6 and locally on OS X 10.7.2.

I couldn't find anything obvious in the dgram.js so I'm guessing its in the lower level.

[bnoordhuis]

Thanks for the writeup. This issue is similar to #2349 in that there is no real memory leak, it just looks that way if you look at RSS only.

If you instrument the code in src/udp_wrap.cc, you'll see that every datagram eventually gets deleted. You can check it for yourself with valgrind --leak-check=full --show-reachable=yes. You'll get a lot of reported leaks (from "eternal" objects that grab memory at start-up) but nothing in the UDP code.

Regarding RSS, it's more visible with UDP than with TCP because Node uses a slab allocator for TCP but plain malloc/free for UDP. Switching over to slab allocation is a TODO.

[quirkey]

Can you explain what changed between 0.4 and 0.6 here that would cause such a big diff?

[bnoordhuis]

v0.4 uses a memory pool-based approach that doesn't quite translate to how v0.6 arranges things. If I have an hour to kill tonight, I'll add slab allocator support to UDP.

[mrb]

FYI, statsd implementations looking to upgrade to v0.6 node will need this slab allocator for UDP as it is for TCP.