[wleeaf]

When linking fails, js_link_module() resets the modules left on the DFS stack to unlinked, but keeps the variable references the partial link took: the import slots of the module function (a counted reference to the exported variable, or a new variable for a namespace re-export) and the var_ref of each local export. The next import of the same module links it again and overwrites those pointers without releasing the old references. They leak in release builds, and debug builds fail the list_empty(&rt->gc_obj_list) assertion in JS_FreeRuntime().

This change releases and clears those references when a module is reset after a failed link, so the module goes back to the state it had before linking. Namespace imports are variables of the module itself and are kept, as are the exports of C modules, which linking does not create. The cleared slots are the same ones that js_bytecode_function_finalizer() and js_free_module_def() release later, so nothing is freed twice.

tests/bug1833.js imports a two-module cycle that fails to link, twice. It covers an import slot, a local export and a namespace re-export (export * as ns from). Without the fix, the test aborts on the assertion in a Debug build (three leaked var_refs) and LeakSanitizer reports a leak under ASan. With the fix, the test and both reproductions from the issue pass in Debug, ASan+UBSan and GC stress builds. The rest of make test, and the test262 module-code, dynamic-import and import directories under ASan+UBSan, show no new failures.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.