`ObjectWrap` destructors run after `CleanupHook`

[mmomtchev]

Version

16.17.0

Platform

Ubuntu 20.04

Subsystem

napi

What steps will reproduce the bug?

Having ObjectWrap objects when destroying the environment. May be related to having stale Persistent objects.

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

Always

What is the expected behavior?

All C++ objects are destroyed before the CleanupHook

What do you see instead?

This is the stack trace

pymport-native.node!Napi::ObjectWrap<pymport::PyObj>::FinalizeCallback(napi_env env, void * data) (/home/mmom/src/pymport/node_modules/node-addon-api/napi-inl.h:4597)
v8impl::RefBase::Finalize(bool) (Unknown Source:0)
node_napi_env__::~node_napi_env__() (Unknown Source:0)
node::Environment::RunCleanup() (Unknown Source:0)
node::FreeEnvironment(node::Environment*) (Unknown Source:0)
node::NodeMainInstance::Run() (Unknown Source:0)
node::Start(int, char**) (Unknown Source:0)
libc.so.6!__libc_start_main(int (*)(int, char **, char **) main, int argc, char ** argv, int (*)(int, char **, char **) init, void (*)(void) fini, void (*)(void) rtld_fini, void * stack_end) (/build/glibc-SzIz7B/glibc-2.31/csu/libc-start.c:308)
_start (Unknown Source:0)

Additional information

No response

[juanarbol]

cc @nodejs/node-api

[legendecas]

Currently, the document only defines that cleanup hooks are run in a reversed order, but no words on if the cleanup hooks are run before any other finalizers. As the status quo, all cleanup hooks are run before the finalizers, regardless of their registration order, as the napi_env's own cleanup is registered before the registration of any addon's cleanup hooks.

I believe it would be more reasonable to run cleanup hooks after pending finalizers are drained. After the cleanup hooks are invoked, there should be no callbacks can calling into the addon again.

[KevinEady]

Hi @legendecas , could this issue also be related to TSFN "release in ObjectWrap destructor" crash stacktraces we are seeing in nodejs/node-addon-api#1109?

[legendecas]

@KevinEady thanks for the link. At first sight, it seems like a finalization order problem too. I'll take a look at both issues.