N-API: memory leak with call to napi_create_function

[anthony-tuininga]

• Version: v12.8.0
• Platform: Linux atc 5.1.20-300.fc30.x86_64 #1 SMP Fri Jul 26 15:03:11 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
• Subsystem:

This is again with respect to the node-oracledb driver (Oracle Database driver for Node.js). I have adjusted the code once again to eliminate any requirement for an Oracle database. I'll attach the test case shortly after this issue is created.

For Oracle Objects I have created a class dynamically at run-time based on the name. This can be seen in the test case as a call to conn.getDbObjectClass(). Internally, the call to conn.getDbObjectClass() calls into a C module which then makes a call to conn._getDbObjectClassJS(). This function then builds the class and stores the result in a cache on the connection called _dbObjectClasses.

When the connection is closed by a call to conn.close(), I have to iterate over the entries in the cache and deliberately break the prototype chain; otherwise, the classes that are built are never garbage collected.

But, even if I do that and the classes are garbage collected, there is still a memory leak. The pattern shows that there are periods of relatively stable memory usage followed by jumps in memory usage. The periods of stable memory usage grow longer as the number of iterations increases but the jump in memory also increases. It would seem that a list of some kind is being populated with intermittent, increasing size allocation. Looking at the heap memory in the Chrome development tools indicates that the memory is all found in noscript_shared_function_infos -- but I'm not sure what that means! Interestingly, though, if I remove the call to napi_define_properties in njsDbObjectType_populate(), the memory leak goes away.

I'm not sure if this is related to the fix introduced in PR #27805 or not, but version 12.0 is the first version that has this issue. Prior to 12.0 the code suffers from the memory leak that that issue corrected.

I hope this is sufficient to discover the source of this issue. Let me know if you need anything else!

[anthony-tuininga]

The test case can be seen in the zip file. Included is a sample stats.txt that demonstrates the memory leak.

Run the tests with

NODE_PATH=$PWD/lib node --expose-gc demo.js

[anthony-tuininga]

I just tried this with Node.js 12.8 (just released) and the issue is still there, unfortunately.

[anthony-tuininga]

Interestingly, a call to napi_define_properties() is not required. A simple call to napi_create_function(), even if that object is never tied to any other object, is all that is required.

[anthony-tuininga]

Here is a much simplified package that contains only a single method called leak_memory() and all it does is calls napi_create_function(). It leaks memory quite rapidly!

issue_28988_simplified.zip

Run it with

node --expose-gc demo.js

You can wait until it finishes or stop it after a few hundred thousand iterations and then examine the file stats.txt, or you can look at the output from the top command.

[legendecas]

Here is a much simplified package that contains only a single method called leak_memory() and all it does is calls napi_create_function(). It leaks memory quite rapidly!

issue_28988_simplified.zip

Run it with

node --expose-gc demo.js

You can wait until it finishes or stop it after a few hundred thousand iterations and then examine the file stats.txt, or you can look at the output from the top command.

Major objects that retained in heap in this case were TickObject which would gets collected once they was been ran.

With changing the while loop in function run to looping with setInterval, the seemingly major leaking behavior had just gone.

Though there still exists a minor heap size increasing on noscript_shared_function_infos.

[anthony-tuininga]

Which version did you use? I am using Node.js 12.8. I modified demo.js to look like this:

const issue_28988 = require('./build/Release/issue_28988.node');
const fs = require('fs');

const statsFileName = "stats.txt";
const maxIters = 2915000;

let numIters = 0;

function performIter() {
  for (let i = 0; i < 1000; i++) {
    numIters++;
    issue_28988.leak_memory();
  }
  console.log("Processed", numIters, "iterations...");
  global.gc();
  const stats = process.memoryUsage();
  const text1 = `${numIters},${stats.rss},${stats.heapTotal},`;
  const text2 = `${stats.heapUsed},${stats.external}\n`;
  fs.appendFileSync(statsFileName, text1 + text2);
}


async function run() {
  fs.writeFileSync(statsFileName, "Num Iters,RSS,Heap Total,Heap Used,Ext\n");
  setInterval(performIter, 0);
}

run()

and I didn't see a whole lot of difference between the two. I see a leak of about 12 bytes/iteration but there are periods of stability followed by a jump. The periods of stability lengthen but the jumps also get bigger. 12 bytes doesn't seem like a lot....until you realize that if you build a class with a number of getter/setter and specialized functions that adds up quickly. If you adjust the call to the leak_memory function to do the following instead:

    for (let j = 0; j < 20; j++) {
      issue_28988.leak_memory();
    }

then the leak jumps to about 250 bytes/iteration. This quite closely matches the behaviour I was seeing with the full test case which probably calls napi_create_function() internally about 20 times.

[mhdawson]

I seem to remember @gabrielschulhof mentioning that V8 never collects functions but I'll have to confirm if that is the case and if we have it documented somewhere.

EDIT: functions created in native code that is.

[mhdawson]

I think @gabrielschulhof is still away for another week and I've not been able to find documentation or earlier issues where that was discussed @hashseed can you confirm one way or the other if V8 collects functions created in native code?

[addaleax]

V8 has something called “template instantiations cache” whose entries refer back to the Function instances indexed by their FunctionTemplates – I could imagine the underlying issue here is that those entries are not cleared when the FunctionTemplate is garbage collected. But this may require a V8 person to confirm and fix.

[hashseed]

@verwaest knows the details here.

Yeah I think we keep instantiated functions around for faster instantiations.

[mhdawson]

@verwaest can you confirm

[verwaest]

Function template::New results in cached templates, whereas Function::New creates an uncached template.

Cached here doesn't mean it's a weak pointer: in the browser for correctness they /need/ to be unique instances that have identity. Since they are mutable objects like any other it's observable, and the fact that they aren't instantiated eagerly is simply a memory and performance optimization. So the cache isn't there (just) for performance, it's actually needed for correctness in the browser.

This cached way of using templates is possibly not what you want. Doesn't Function::New fit your usecase?

[anthony-tuininga]

This cached way of using templates is possibly not what you want. Doesn't Function::New fit your usecase?

I am not using the C++ API directly, but indirectly through N-API. Is there a way to create a function with Function::New() using N-API?