Question: Roadmap, Project Status, Things in General.

[overflowz]

I'm sure this question was asked previously quite a lot, but it's hard to track everything together, so I'm asking them here:

1. What is the status of the project? Are there any plans to actively maintain the library or it's being abandoned(ish)?
2. What is the roadmap of v6? What needs to be done to make it stable?
3. There were reported quite issues before (memory leaks, crashes, etc). Is v5 (or v6) actually stable (by stable I mean is it recommended to use in a production project)?

Thank you.

[aminya]

v5 is stable and is already in use in production. See Hydrogen as an example.

There are a couple of issues with v6:

• Access violation that happens after this test:
  Access violation in TypedArrayOf nodejs/node-addon-api#965

• Memory leaks (GC failures). The tests for these fail:

  1) socket with inproc close
       in gc finalizer
         should release reference to context:
      AssertionError: expected false to equal true
      + expected - actual
      -false
      +true
      
      at Context.<anonymous> (test/unit/socket-close-test.ts:156:16)
  2) socket with tcp close
       in gc finalizer
         should release reference to context:
      AssertionError: expected false to equal true
      + expected - actual
      -false
      +true
      
      at Context.<anonymous> (test/unit/socket-close-test.ts:156:16)
  3) socket with ipc close
       in gc finalizer
         should release reference to context:
      AssertionError: expected false to equal true
      + expected - actual
      -false
      +true
      
      at Context.<anonymous> (test/unit/socket-close-test.ts:156:16)

Any contribution to fix the issues is appreciated.

[overflowz]

Thank you. I'll try to have a look into the memory leak issue whenever I can (NB: haven't used C++ for ages, could take time).

[overflowz]

@aminya re memory leaks: tried my best, but I have no idea why it is leaking (either because of my C++ knowledge or the NAPI). I'll just provide what I tried and maybe it will be useful for you.

Something interesting I found here: https://github.com/zeromq/zeromq.js/blob/master/src/socket.cc#L79 which creates a strong reference to the context that was passed and when the socket is garbage collected, it unrefs the context, but the context destructor itself is being called after a few seconds (this, I don't understand why). Even if I don't reset the ref, it has the same behavior.

When I set the weak reference, it worked, but it's not the correct behavior, because if context will be garbage collected, socket.context will be also garbage collected.

Here's the sample code that reproduces it:

const weak = require("weak-napi")
const zmq = require("./lib")

const task = async () => {
  let context = new zmq.Context()
  new zmq.Dealer({context})

  weak(context, () => {
    console.info("memory freed")
  })

  context = undefined
  global.gc()
}

async function run() {
  await task()
  global.gc()

  /*
  * but if I run setImmediate(() => global.gc())
  * then it works.
  */

  // if I remove this, I get SIGSEGV
  setInterval(() => {}, 1000) // keep the event loop busy
}

run()

logs I get from SIGSEGV (if I won't keep event loop busy & call gc in the main loop)

* thread #1, name = 'node', stop reason = signal SIGSEGV: invalid address (fault address: 0x61)
  * frame #0: 0x0000000000000061
    frame #1: 0x00000000009b8de7 node`v8impl::(anonymous namespace)::RefBase::Finalize(bool) + 231
    frame #2: 0x00000000009d85cf node`node_napi_env__::~node_napi_env__() + 95
    frame #3: 0x00000000009a9fdb node`node::Environment::RunCleanup() + 619
    frame #4: 0x000000000096d547 node`node::FreeEnvironment(node::Environment*) + 71
    frame #5: 0x0000000000a4483f node`node::NodeMainInstance::Run() + 271
    frame #6: 0x00000000009d1e15 node`node::Start(int, char**) + 277
    frame #7: 0x00007ffff7a810b3 libc.so.6`__libc_start_main + 243
    frame #8: 0x00000000009694cc node`_start + 41

[willingc]

@aminya Let's move the memory leak troubleshooting to its own issue.

[willingc]

@aminya and @overflowz Let's move the memory leak discussion here: #466

[aminya]

That's a good idea. I will close this in favor of #466