What could cause a memory leak in Node.js with detached DOM references?

[Elizabeth36]

I’ve been trying to track down a memory leak in my Node.js service for days, and the heap snapshots show this huge number of detached DOM tree references piling up, even though it’s a backend process. I’m completely stumped on how a server-side application could even be creating DOM nodes in the first place. Has anyone else run into something this bizarre?

[JohnXM]

I ran into this myself when our Node service used Puppeteer to render HTML on demand. The heap dump kept showing a ton of detached DOM trees after we finished a job. It turned out we were creating a brand new browser page per request and never closing it, so the browser kept references around. The fix was to reuse a single browser instance and close every page when the job finishes, plus null out references in any closures that held onto handles. After we did that, memory drift slowed to a halt.

[Gregory.T]

Another thing I tried was hunting with a lightweight profiler and printing out where the handles were coming from. We found a module that kept a global cache of parsed HTML, and some event listeners that stuck around in long-lived workers. We trimmed the cache size and removed those listeners when a worker ended.

[JacobUG]

I'm not sure that's the real problem, though. Could be a red herring from a testing harness or a busted heap snapshot. Maybe your server isn't leaking DOM-like objects at all; maybe it's a misinterpreted reference or something in the tracing tool.

[JoshuaXG]

The memory kept creeping up after we deployed a small feature flag that runs in a separate process. After we rolled back to a single process pool and added a teardown hook, the growth stopped at a baseline. Not fully confident, but that helped in practice.