`ObjectWrap` cleanup hooks break pre-built addons on Node.js 26.0.0-26.3.1 runtimes · Issue #65262 · nodejs/node · GitHub
Skip to content

ObjectWrap cleanup hooks break pre-built addons on Node.js 26.0.0-26.3.1 runtimes #65262

Open
Open
ObjectWrap cleanup hooks break pre-built addons on Node.js 26.0.0-26.3.1 runtimes#65262
Labels
addonsIssues and PRs related to native addons.c++Issues and PRs that require attention from people who are familiar with C++.

Description

@dyalevog
dyalevog
opened on Aug 13, 2026

Version

Node.js headers 26.4.0 or newer
Node.js runtime 26.0.0 up to and including 26.3.1

Platform

Not platform specific, but used:
Linux 7.0.0-28-generic #28~24.04.1-Ubuntu x86_64 x86_64 x86_64 GNU/Linux

Subsystem

src, addons

What steps will reproduce the bug?

The crash depends on header and runtime version. So you will need headers from e.g. Node.js 26.4.0 and two runtimes (e.g. 26.2.0 and 26.4.0)

  1. Sample that just uses ObjectWrap
    addon.cc:
#include <node.h>
#include <node_object_wrap.h>

using namespace v8;

class Thing : public node::ObjectWrap {
 public:
  static void New(const FunctionCallbackInfo<Value>& args) {
    (new Thing())->Wrap(args.This());
  }
};

void Init(Local<Object> exports) {
  Isolate* isolate = Isolate::GetCurrent();
  Local<Context> context = isolate->GetCurrentContext();
  Local<FunctionTemplate> tpl = FunctionTemplate::New(isolate, Thing::New);
  tpl->InstanceTemplate()->SetInternalFieldCount(1);
  exports->Set(context,
               String::NewFromUtf8(isolate, "Thing").ToLocalChecked(),
               tpl->GetFunction(context).ToLocalChecked()).Check();
}

NODE_MODULE(NODE_GYP_MODULE_NAME, Init)

index.js:

const { Thing } = require('./addon.node');

let junk = [];
for (let i = 0; i < 300000; i++) {
  new Thing();                          // wrapped object, immediately unreachable
  junk.push({ a: i });                  // keep allocation rate high so V8 collects on its own
  if (junk.length > 1000) junk = [];
}
console.log('survived');
  1. Compile against 26.4.0 (or newer if you want)
g++ -std=c++20 -fPIC -shared \
    -I</path/to/node-v26.4.0-linux-x64/include/node> \
    -DNODE_GYP_MODULE_NAME=addon \
    -o addon.node addon.cc
  1. Run same binary against two different Node.js versions
# this one will run fine
<path/to/node_26.4> index.js

# this one will crash
<path/to/node_26.2> index.js

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

Deterministically with 5/5 runs.
See this table for when it crashes:

hdr \ rt 26.0.0 26.3.1 26.4.0 26.7.0
26.0.0 ok ok ok ok
26.3.1 ok ok ok ok
26.4.0 crash crash ok ok
26.7.0 crash crash ok ok

I.e. it crashes with headers >= 26.4.0 when runtime <= 26.3.1.

A explicit trigger of the gc via global.gc() will not cause the failure, it has to be an allocation-driven one.

What is the expected behavior? Why is that the expected behavior?

A pre-built addon that is built against headers of one 26.x release should keep working on another 26.x runtime

What do you see instead?

  #  node[278507]: void node::RemoveEnvironmentCleanupHook(Isolate *, CleanupHook, void *) at ../src/api/hooks.cc:130
  #  Assertion failed: (env) != nullptr

----- Native stack trace -----

 1: 0x813228 node::Assert(node::AssertionInfo const&) [node]
 2: 0x891b90 node::RemoveEnvironmentCleanupHook(v8::Isolate*, void (*)(void*), void*) [node]
 3: 0x73f036ca4045 node::ObjectWrap::RemoveCleanupHook() [/home/user/reproducer/addon.node]
 4: 0x73f036ca393a node::ObjectWrap::~ObjectWrap() [/home/user/reproducer/addon.node]
 5: 0x73f036ca41ec Thing::~Thing() [/home/user/reproducer/addon.node]
 6: 0x73f036ca420c Thing::~Thing() [/home/user/reproducer/addon.node]
 7: 0x73f036ca3fdd node::ObjectWrap::WeakCallback(v8::WeakCallbackInfo<node::ObjectWrap> const&) [/home/user/reproducer/addon.node]
 8: 0xe18a09  [node]
 9: 0xeb3f61  [node]
10: 0xec4582  [node]
11: 0xec425f  [node]
12: 0x194cdf7  [node]
13: 0xeb0372  [node]
14: 0xea3914  [node]
15: 0xea373c  [node]
16: 0xea30cf  [node]
17: 0xe7f25d  [node]
18: 0x133d781  [node]
19: 0x73f02763ea76 
Aborted (core dumped)

Additional information

The causing code change in 26.4.0 is the RemoveCleanupHook(); line added to destructor in commit 7ac3fe1. The call interacts with the improvement of the RemoveEnvironmentCleanupHook function in 1723773.

When the destructor is called due to headers being 26.4.0 or newer, but the runtime being <= 26.3.1, then it can trigger the CHECK_NOT_NULL(env); of the RemoveEnvironmentCleanupHook function.

Refs: #63642 #63985

Activity

  1. Flarna
    added
    addonsIssues and PRs related to native addons.
    c++Issues and PRs that require attention from people who are familiar with C++.
    on Aug 13, 2026

  2. roy-trgscreen commented on Aug 20, 2026

    @roy-trgscreen
    roy-trgscreen
    on Aug 20, 2026

    The same assertion exists on the 24.x LTS line, but there it does not need a header/runtime
    mismatch: headers and runtime both at 24.19.0 abort deterministically.

    Using your reproducer unchanged, on Darwin 25.5.0 arm64 with the official tarballs, 5/5 runs
    per cell:

    hdr \ rt 24.18.1 24.19.0
    24.18.1 ok ok
    24.19.0 crash crash 
    #  node[52504]: void node::RemoveEnvironmentCleanupHook(Isolate *, CleanupHook, void *) at ../src/api/hooks.cc:142
#  Assertion failed: (env) != nullptr
4: node::ObjectWrap::RemoveCleanupHook() [addon-hdr-24.19.0.node]
5: node::ObjectWrap::~ObjectWrap() [addon-hdr-24.19.0.node]

    The reason the diagonal fails there is that 24.19.0 got the RemoveCleanupHook() half of the
    change (#63642) but not the 1723773d half that you identified, so no 24.x runtime tolerates
    it:

    $ curl -s https://raw.githubusercontent.com/nodejs/node/v24.19.0/src/node_object_wrap.h | grep -c 'RemoveCleanupHook()'
2
$ curl -s https://raw.githubusercontent.com/nodejs/node/v24.19.0/src/api/hooks.cc | grep -c CleanupHookThunk
0

    v24.x-staging is in the same state today. Filed separately as #65446 since the fix
    there is a backport rather than a runtime upgrade, but happy for it to be folded into this
    issue if you would rather keep it in one place.

  3. everett1992
    added 2 commits that reference this issue on Aug 28, 2026

    src: fix use-after-free in CleanupHookThunkRun

    6dd9a72

    src: fix use-after-free in CleanupHookThunkRun

    dd2fa31
  4. nodejs-github-bot
    added a commit that references this issue on Sep 4, 2026

    src: fix use-after-free in CleanupHookThunkRun

    03e2b9b
  5. aduh95
    added 2 commits that reference this issue on Sep 7, 2026

    src: fix use-after-free in CleanupHookThunkRun

    8cfe7ae

    src: fix use-after-free in CleanupHookThunkRun

    4eb6133
  6. everett1992
    added a commit that references this issue on Sep 10, 2026

    src: fix use-after-free in CleanupHookThunkRun

    fa73926
  7. aduh95
    added a commit that references this issue on Sep 15, 2026

    src: fix use-after-free in CleanupHookThunkRun

    f66ed89
  8. panva
    added a commit that references this issue on Sep 20, 2026

    src: fix use-after-free in CleanupHookThunkRun

    df46f87
  9. aduh95
    added a commit that references this issue on Sep 21, 2026

    src: fix use-after-free in CleanupHookThunkRun

    5570a84
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    addonsIssues and PRs related to native addons.c++Issues and PRs that require attention from people who are familiar with C++.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions