You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Possible ExitEvent leak when BlockingCall() returns napi_closing #938
Possible ExitEvent leak when BlockingCall() returns napi_closing
I found a possible native heap leak in the pty exit watcher when the thread-safe function is closing.
Files: src/unix/pty.cc, src/win/conpty.cc
Function: SetupExitCallback
Relevant Unix code:
auto callback = [](Napi::Env env, Napi::Function cb, ExitEvent *exit_event) {
cb.Call({Napi::Number::New(env, exit_event->exit_code),
Napi::Number::New(env, exit_event->signal_code)});
delete exit_event;
};
// ...
ExitEvent *exit_event = new ExitEvent;
// fill exit_eventauto status = tsfn.BlockingCall(exit_event, callback);
switch (status) {
case napi_closing:
break;
case napi_queue_full:
Napi::Error::Fatal("SetupExitCallback", "Queue was full");
case napi_ok:
if (tsfn.Release() != napi_ok) {
Napi::Error::Fatal("SetupExitCallback", "ThreadSafeFunction.Release() failed");
}
break;
}
The Windows implementation has the same ownership pattern.
The ExitEvent is deleted only by the JS-thread callback. If BlockingCall()
returns napi_closing, the item was not queued and that callback will not run.
The case napi_closing: branch then drops the only pointer to exit_event.
This is a small teardown-race leak: one ExitEvent per pty whose exit races
Node-API environment shutdown.
Suggested fix: delete exit_event in the napi_closing branch, where ownership
was not transferred to the callback queue.
Activity