-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows build of Node.js is using a static C runtime which leads to having separate heaps for its addons #40926
Comments
@mscdex, do you think it would be possible to route |
In fact, |
The underlying problem is impossible to solve without a major ABI change and there is a workaround for addons using |
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 lingoHow 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_heap.cpp:996
free
doesn't workAdditional 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
The text was updated successfully, but these errors were encountered: