node.js c++ addon - afraid of memory leak

Question

first of all I admit I'm a newbie in C++ addons for node.js.

I'm writing my first addon and I reached a good result: the addon does what I want. I copied from various examples I found in internet to exchange complex data between the two languages, but I understood almost nothing of what I wrote.

The first thing scaring me is that I wrote nothing that seems to free some memory; another thing which is seriously worrying me is that I don't know if what I wrote may helps or creating confusion for the V8 garbage collector; by the way I don't know if there are better ways to do what I did (iterating over js Object keys in C++, creating js Objects in C++, creating Strings in C++ to be used as properties of js Objects and what else wrong you can find in my code).

So, before going on with my job writing the real math of my addon, I would like to share with the community the nan and V8 part of it to ask if you see something wrong or that can be done in a better way.

Thank you everybody for your help,

iCC

#include <map>
#include <nan.h>

using v8::Array;
using v8::Function;
using v8::FunctionTemplate;
using v8::Local;
using v8::Number;
using v8::Object;
using v8::Value;
using v8::String;
using Nan::AsyncQueueWorker;
using Nan::AsyncWorker;
using Nan::Callback;
using Nan::GetFunction;
using Nan::HandleScope;
using Nan::New;
using Nan::Null;
using Nan::Set;
using Nan::To;

using namespace std;

class Data {
public:
    int dt1;
    int dt2;
    int dt3;
    int dt4;
};

class Result {
public:
    int   x1;
    int   x2;
};

class Stats {
public:
    int stat1;
    int stat2;
};

typedef map<int, Data>    DataSet;
typedef map<int, DataSet> DataMap;

typedef map<float, Result>    ResultSet;
typedef map<int,   ResultSet> ResultMap;

class MyAddOn: public AsyncWorker {
private:
    DataMap   *datas;
    ResultMap  results;
    Stats      stats;

public:
    MyAddOn(Callback *callback, DataMap *set): AsyncWorker(callback), datas(set) {}
    ~MyAddOn() { delete datas; }

    void Execute () {
        for(DataMap::iterator i = datas->begin(); i != datas->end(); ++i) {
            int      res   =  i->first;
            DataSet *datas = &i->second;

            for(DataSet::iterator l = datas->begin(); l != datas->end(); ++l) {
                int   dt4  =  l->first;
                Data *data = &l->second;

                // TODO: real population of stats and result
            }

            // test result population
            results[res][res].x1 = res;
            results[res][res].x2 = res;
        }

        // test stats population
        stats.stat1 = 23;
        stats.stat2 = 42;
    }

    void HandleOKCallback () {
        Local<Object> obj;
        Local<Object> res  = New<Object>();
        Local<Array>  rslt = New<Array>();
        Local<Object> sts  = New<Object>();
        Local<String> x1K  = New<String>("x1").ToLocalChecked();
        Local<String> x2K  = New<String>("x2").ToLocalChecked();
        uint32_t      idx  = 0;

        for(ResultMap::iterator i = results.begin(); i != results.end(); ++i) {
            ResultSet *set = &i->second;

            for(ResultSet::iterator l = set->begin(); l != set->end(); ++l) {
                Result *result = &l->second;

                // is it ok to declare obj just once outside the cycles?
                obj = New<Object>();

                // is it ok to use same x1K and x2K instances for all objects?
                Set(obj, x1K, New<Number>(result->x1));
                Set(obj, x2K, New<Number>(result->x2));
                Set(rslt, idx++, obj);
            }
        }

        Set(sts, New<String>("stat1").ToLocalChecked(), New<Number>(stats.stat1));
        Set(sts, New<String>("stat2").ToLocalChecked(), New<Number>(stats.stat2));

        Set(res, New<String>("result").ToLocalChecked(), rslt);
        Set(res, New<String>("stats" ).ToLocalChecked(), sts);

        Local<Value> argv[] = { Null(), res };

        callback->Call(2, argv);
    }
};

NAN_METHOD(AddOn) {
    Local<Object> datas    = info[0].As<Object>();
    Callback     *callback = new Callback(info[1].As<Function>());
    Local<Array>  props    = datas->GetOwnPropertyNames();
    Local<String> dt1K     = Nan::New("dt1").ToLocalChecked();
    Local<String> dt2K     = Nan::New("dt2").ToLocalChecked();
    Local<String> dt3K     = Nan::New("dt3").ToLocalChecked();
    Local<Array>  props2;
    Local<Value>  key;
    Local<Object> value;
    Local<Object> data;
    DataMap      *set      = new DataMap();
    int           res;
    int           dt4;
    DataSet      *dts;
    Data         *dt;

    for(uint32_t i = 0; i < props->Length(); i++) {
        // is it ok to declare key, value, props2 and res just once outside the cycle?
        key    = props->Get(i);
        value  = datas->Get(key)->ToObject();
        props2 = value->GetOwnPropertyNames();
        res    = To<int>(key).FromJust();
        dts    = &((*set)[res]);

        for(uint32_t l = 0; l < props2->Length(); l++) {
            // is it ok to declare key, data and dt4 just once outside the cycles?
            key  = props2->Get(l);
            data = value->Get(key)->ToObject();
            dt4  = To<int>(key).FromJust();
            dt   = &((*dts)[dt4]);

            int dt1 = To<int>(data->Get(dt1K)).FromJust();
            int dt2 = To<int>(data->Get(dt2K)).FromJust();
            int dt3 = To<int>(data->Get(dt3K)).FromJust();

            dt->dt1 = dt1;
            dt->dt2 = dt2;
            dt->dt3 = dt3;
            dt->dt4 = dt4;
        }
    }

    AsyncQueueWorker(new MyAddOn(callback, set));
}

NAN_MODULE_INIT(Init) {
    Set(target, New<String>("myaddon").ToLocalChecked(), GetFunction(New<FunctionTemplate>(AddOn)).ToLocalChecked());
}

NODE_MODULE(myaddon, Init)

One year and half later...

If somebody is interested, my server is up and running since my question and the amount of memory it requires is stable.

I can't say if the code I wrote really does not has some memory leak or if lost memory is freed at each thread execution end, but if you are afraid as I was, I can say that using same structure and calls does not cause any real problem.

Answer 1

You do actually free up some of the memory you use, with the line of code:

~MyAddOn() { delete datas; }

In essence, C++ memory management boils down to always calling delete for every object created by new. There are also many additional architecture-specific and legacy 'C' memory management functions, but it is not strictly necessary to use these when you do not require the performance benefits.

As an example of what could potentially be a memory leak: You're passing the object held in the *callback pointer to the function AsyncQueueWorker. Yet nowhere in your code is this pointer freed, so unless the Queue worker frees it for you, there is a memory leak here.

You can use a memory tool such as valgrind to test your program further. It will spot most memory problems for you and comes highly recommended.

One thing I've observed is that you often ask (paraphrased):

Is it okay to declare X outside my loop?

To which the answer actually is that declaring variables inside of your loops is better, whenever you can do it. Declare variables as deep inside as you can, unless you have to re-use them. Variables are restricted in scope to the outermost set of {} brackets. You can read more about this in this question.

is it ok to use same x1K and x2K instances for all objects?

In essence, when you do this, if one of these objects modifies its 'x1K' string, then it will change for all of them. The advantage is that you free up memory. If the string is the same for all these objects anyway, instead of having to store say 1,000,000 copies of it, your computer will only keep a single one in memory and have 1,000,000 pointers to it instead. If the string is 9 ASCII characters long or longer under amd64, then that amounts to significant memory savings.

By the way, if you don't intend to modify a variable after its declaration, you can declare it as const, a keyword short for constant which forces the compiler to check that your variable is not modified after declaration. You may have to deal with quite a few compiler errors about functions accepting only non-const versions of things they don't modify, some of which may not be your own code, in which case you're out of luck. Being as conservative as possible with non-const variables can help spot problems.