Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

No adapter implements napi_add_env_cleanup_hook, forcing per-environment native state to be process-global

Open
  • Is something wrong?
#215 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
50/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
cpp, javascript
Domain
api, backend

Research direction

Start by comparing the Node-API adapter files js_native_api_chakra.cc, js_native_api_javascriptcore.cc, js_native_api_quickjs.cc and js_native_api_v8.cc against napi-inl.h's Env::AddCleanupHook usage. Then inspect Polyfills/URL/Source/URL.cpp and Polyfills/URL/Include/Babylon/Polyfills/URL.h; done means cleanup hooks are available across the adapters and the blob URL store is scoped and cleaned up per environment.

Written by the indexing model from the issue text.

Description

Summary

There is no portable way to run native cleanup when a JS environment is torn down, because no Node-API adapter in Core/Node-API/Source implements napi_add_env_cleanup_hook:

$ grep -rn "napi_add_env_cleanup_hook" Core/Node-API/Source
(no matches)

The only reference anywhere in the repo is the vendored node-addon-api header Core/Node-API/Include/Shared/napi/napi-inl.h, which calls it from Napi::Env::AddCleanupHook. That call has no implementation behind it in js_native_api_chakra.cc, js_native_api_javascriptcore.cc, js_native_api_quickjs.cc or js_native_api_v8.cc.

Impact

Native polyfill state that logically belongs to an environment has to be made process-global instead, and then leaks for the life of the process.

The concrete case is the blob URL store added in #207 (Polyfills/URL/Source/URL.cpp). URL.createObjectURL registers an entry that is normally released by URL.revokeObjectURL. Entries that are never revoked should be released when the environment goes away -- that is what a browser does at unload. With no teardown hook the store must be process-global, so an embedder that creates and destroys environments over the process lifetime accumulates every un-revoked blob URL, and the buffers behind them, until the process exits.

Polyfills/URL/Include/Babylon/Polyfills/URL.h documents the store as process-global for exactly this reason, and RegisterObjectURL/RevokeObjectURL already take a Napi::Env that is currently unused, kept for future per-env scoping.

Suggested fix

Implement napi_add_env_cleanup_hook and napi_remove_env_cleanup_hook in the adapters, then scope the blob URL store per environment and drop its entries from the cleanup hook.

Notes

Not covered by the existing issues: #194 was the JSC napi_typeof bug, #213 was the UrlLib blob: scheme resolver (implemented in #207), and #214 is the UrlLib Apple lifetime bug.

Dominant language
C++
Stars
22
Forks
23
Avg merge
4d 8h
Merged PRs (30d)
3

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from BabylonJS/JsRuntimeHost

All issues in BabylonJS/JsRuntimeHost

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.