Analysing Memory LeaksArturo Martinez Minguez

IceMobile loves unit tests. We encourage developers to accompany their pull requests with all the pertinent unit tests, otherwise its chances of being approved become close to null. This, of course, has never been source of concern. Until, one day, I ran my Mocha–powered unit tests, and sat back to see their outcome. After around 1,050 unit tests, things started to get suspiciously slow and fail randomly:

30 seconds to run a unit test that should barely take some milliseconds is by no means normal. Running top next to the unit tests gave me these dramatic numbers:

This definitely reeks of a memory leak.

Using node-memwatch to detect memory leaks node-memwatch is a module that, amongst other features, will warn you whenever the heap usage has increased for five consecutive garbage collections. You can achieve this by subscribing to the leak even

In case of a possible memory leak, the console.dir above will print the following:

But this in itself does not really point us towards any leaky place in our code. node-memwatch also brings you the possibility of computing a diff between two snapshots, but I will skip that since I prefer the insights provided by node-heapdump.

Deeper analysis with node-heapdump

node-heapdump will help us hunt down our leak. This module allows you to dump V8 heap snapshots to a file. We will extend the previous code with the following:

This code will dump the snapshot in the folder /var/local. You can open it with Google Chrome's developer toolbar (F12 or alt-cmd-i), under the Profiles tab:

Almost half gigabyte in Strings does definitely not look good at all. By collapsing the String section, we will be able to see more details about the objects.

Now, this is something I can easily recognize and hunt down in my code. It looks like the same WSDL file has been loaded over and over again. A quick search of usages pointed me to a leaky class, which was promptly fixed.