Windows build of Node.js is using a static C runtime which leads to having separate heaps for its addons

[mmomtchev]

Version

v16.10.0

Platform

Windows

Subsystem

node-gyp

What steps will reproduce the bug?

Use the default Windows build settings in node-gyp for Node addon - one will obtain a so-called "/MT" or "/MTd" build in Windows lingo

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior?

Ideally, Node.js should share a heap with its addons - an "/MD" or "/MDd" build in Windows lingo - but the reality is that this is not so simple on Windows - and changing the link settings would break all existing addons that come as prebuilt binaries

What do you see instead?

Node addons have a separate heap on Windows

• Debug builds fail with an assert in debug_heap.cpp:996
• Release builds silently leak memory - the free doesn't work

Additional information

Normally having separate heaps is not a showstopper - in fact, Microsoft recommends that all DLLs have their own separate memory management and that objects allocated in one DLL are always freed in the same DLL.
With the current API, Nan::NewBuffer and some callback pointers are notable exceptions.

See also:

nodejs/node-gyp#1686
https://docs.microsoft.com/en-us/answers/questions/240332/assert-when-using-mtd-dynamic-library.html

[mmomtchev]

@mscdex, do you think it would be possible to route malloc and free from the add-on to the C runtime included in the main exe? This way old binary packages continue to work as they are now and newly rebuilt binaries will have a shared heap with the main exe?

[mmomtchev]

In fact, Nan::NewBuffer has an optional FreeCallback argument - if a module is expected to work on Windows this argument is to be used at all times

[mmomtchev]

The underlying problem is impossible to solve without a major ABI change and there is a workaround for addons using Nan::NewBuffer on Windows