Repository navigation
compiler memory leak in 5.8.x and upwards #62143
Description
🔎 Search Terms
5.8, mem
🕗 Version & Regression Information
- This changed between versions 5.7 and 5.8
⏯ Playground Link
No response
💻 Code
https://github.com/fxdave/cuple/pull/new/typescript-issue-5-8-memory-leak
🙁 Actual behavior
$ npx tsc
<--- Last few GCs --->
[34857:0x559d92e7c000] 42329 ms: Scavenge (interleaved) 4081.2 (4090.1) -> 4078.8 (4098.6) MB, pooled: 0 MB, 5.79 / 0.00 ms (average mu = 0.281, current mu = 0.252) allocation failure;
[34857:0x559d92e7c000] 43481 ms: Mark-Compact (reduce) 4089.9 (4103.4) -> 4081.8 (4088.4) MB, pooled: 0 MB, 59.32 / 0.00 ms (+ 880.5 ms in 176 steps since start of marking, biggest step 5.5 ms, walltime since start of marking 998 ms) (average mu = 0.2
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0x559d50eec8b4 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
2: 0x559d5140dd34 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
3: 0x559d5140de3b v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
4: 0x559d5169e0ac [node]
5: 0x559d516a4356 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [node]
6: 0x559d516a4467 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector, v8::base::TimeTicks) [node]
7: 0x559d516b3bc4 [node]
8: 0x559d516b6dd4 [node]
9: 0x559d52146ba7 [node]
fish: Job 1, 'npx tsc' terminated by signal SIGABRT (Abort)
🙂 Expected behavior
$ npx tsc
(List of type errors.)
Additional information about the issue
NOTE:
It's not a node(24.4.1) issue, I tried with a different node version (node:22-bookworm from dockerhub).
The project is tiny.
I tried adding all my free rams to node (12GB) it ate it.
Steps to reproduce:
# Download this branch: https://github.com/fxdave/cuple/pull/new/typescript-issue-5-8-memory-leak
git clone -b typescript-issue-5-8-memory-leak https://github.com/fxdave/cuple.git
cd cuple
# Setup:
npm i
make build # Important!
# run npx tsc in the tests folder
cd test
npx tsc(the code contains errors, but that shouldn't matter.)
Activity
RyanCavanaugh commentedon Jul 29, 2025
I can't repro this through
tscinvocations.fxdave commentedon Jul 30, 2025
I'm not sure why,
Could you please try this?:
docker run -it --rm -w /app node:22-bookworm sh -c 'git clone -b typescript-issue-5-8-memory-leak https://github.com/fxdave/cuple.git . && npm i && make build && cd test && npx tsc'This is the log I get with it:
RyanCavanaugh commentedon Jul 30, 2025
We need a repro that is just invoking tsc. If you have a specific environment or outer script that is needed to reproduce the issue, then you need to figure out what specifically about that is causing an issue -- we are not resourced to investigate external tools
fxdave commentedon Jul 31, 2025
Ryan Cavanaugh (@RyanCavanaugh) You mentioned you couldn’t reproduce the issue, which surprised me since I was able to reproduce it even in a container isolated from my environment. That’s why I provided a simple one-liner so you can quickly verify whether the memory leak exists on your end. The memory leak is not caused by any external tools, and it is really only a tsc invocation, but dependencies have to be installed first. If the leak isn’t reproducible for you, it’s hard to move forward, since the issue would appear to be specific to my current kernel, however I assume that's unlikely.
RyanCavanaugh commentedon Jul 31, 2025
It's extremely rare for us to get an issue that depends on a specific environment, and extremely common for bug reports that involve "run this build script" to be an issue with the build scripts or build script runner rather than TS itself.
The only thing I'm asking for here is that the repo be an invocation of
tsc; if you have OS / npm / disk layout / other factors that are relevant, please list them, we're happy to investigate as long as we don't need to run your custom build scripts as part of that.Renegade334 commentedon Jul 31, 2025
This specific case hits a few edges all at once.
zodand sometimes importingzod/v4.typesfield being erroneously appended to subdirectory lookups, which was addressed by Fix incorrect usage of package.jsontypes/mainin package subdirectories #60696.exportsmap, but your project is using"module": "commonjs"(ie."moduleResolution": "node10"), which doesn't honourexports.v4/index.d.ctsandv4/index.d.tsrespectively).zodandzod/v4is actually two identical-looking but discrete symbols.In an ideal world, the compiler should be reporting a TS2589 and aborting gracefully, but everything else is intended behaviour.
fxdave commentedon Aug 1, 2025
René (@Renegade334) Thanks. Indeed it ran with 30Gigs using swapfile for additional memory.
5.7.3 ran it using 100MB (
NODE_OPTIONS="--max-old-space-size=100").If it's not leak at least it is very inefficient on memory.
Renegade334 commentedon Aug 1, 2025
Would suggest either using one import consistently (
zodorzod/v4), or changing the module option in your tsconfigs tonode16(to enable exports maps), so that these imports resolve to the same module path.The
commonjsmodule option corresponds to pre-Node v12 module behaviour; under this schema, those two module imports are resolved to different paths. This only worked for you previously due to a small bug in TypeScript's module resolver, which meant it was accidentally doing what you intended.fxdave commentedon Aug 7, 2025
René (@Renegade334) Thanks for the support. If you feel like it is worth keeping the issue open for the TS2589 message, I leave it open and let you guys close it.
jofflin commentedon Sep 15, 2025
Wow,
thank for clarification. That issue cost me a whole day for sure. I tried everything, including switching to tsgo, testing with different IDE's and more. Just removing all zod/v4 and replacing it with zod resolved the issue.
Thanks!