Memory leak on Node v20

[felladrin]

Bug description

Issue: When running npx tsx example.ts, memory usage grows infinitely. It happens independently of the file extension (tested with .ts, .js, .mjs).

Expectation: Memory should be stable (~30 MB) while waiting for the user input.

Confirmation: For comparison, it doesn't happen when running npx jiti example.ts.

tsx	jiti

Reproduction

// example.ts
import readline from "node:readline";

const rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout,
});

rl.question("What is your name? ", (name) => {
  console.log(`Hello ${name}`);
  rl.close();
});

Environment

System:
    OS: macOS 13.3.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 11.64 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.0.0 - /opt/homebrew/bin/node
    npm: 9.6.5 - /opt/homebrew/bin/npm

Note: I haven't installed tsx globally, but the version running through npx is the following:

tsx v3.12.6
node v20.0.0

Can you work on a fix?

• I’m interested in opening a pull request to address this issue.

[privatenumber]

I'm unable to reproduce this and the reproduction doesn't feel sufficient.

Would like to see a better way to measure memory usage (e.g. via process.memoryUsage()). Currently, I'm not even sure if your Activity Monitor is reflecting the correct process.

(Also, shouldn't the baseline be Node.js?)

Closing this out as per the Issue guidelines for lack of reproduction. Happy to re-open when it's reproducible.

[LangLangBart]

@felladrin ¹

• can reproduce the issue since I updated to nodejs/node v20.0.0 (18/Apr/23)
• switching back to v19.9.0 the issue isn't reproducible
  • tested with Schniz/fnm

Footnotes

1. Can you leave the name of your VS Code theme under your image ? Colors/font look great. ↩

[felladrin]

Thanks for confirming, @LangLangBart!¹

Footnotes

1. The theme is Stockholm by @ludviglundgren 😄 ↩

[LangLangBart]

The theme is Stockholm

thanks

---

• Tested the latest nightly node version on my intel mac
• coudln't test the exact same setup as described in the description as an error would occur
  • All version numbers passed to esbuild must be in the format "X", "X.Y", or "X.Y.Z ... Invalid version: "21.0.0-nightly202304287ae1360358""
• used a similar setup and the issue is no longer reproducible
  • I assume that this memory problem should be fixed with the next node release.
• Ref: Using custom loaders results in a load loop / OOM nodejs/node#47566

test setup

touch require.cjs
touch loader.mjs
cat << EOF > test.mjs
import { createInterface } from 'readline';

const rl = createInterface({
input: process.stdin,
output: process.stdout,
});

rl.question('Please enter your answer: ', () =>rl.close());
EOF

node v20

node --version
# v20.0.0

node --require ./require.cjs --loader ./loader.mjs test.mjs
# check memory % in a second terminal tab for node
while true; do ps -A -o %mem,comm | grep node; sleep 2; done
# 1.2 node
# 4.5 node
# 8.3 node
# 11.5 node

node latest nightly

curl --silent --remote-name https://nodejs.org/download/nightly/v21.0.0-nightly202304287ae1360358/node-v21.0.0-nightly202304287ae1360358-darwin-x64.tar.gz
tar -xzf node-v21.0.0-nightly202304287ae1360358-darwin-x64.tar.gz
export PATH="$HOME/node-v21.0.0-nightly202304287ae1360358-darwin-x64/bin:$PATH"

node --version
# v21.0.0-nightly202304287ae1360358

node --require ./require.cjs --loader ./loader.mjs test.mjs
while true; do ps -A -o %mem,comm | grep node; sleep 2; done
# 0.5 node
# 0.5 node
# 0.5 node
# 0.5 node

[privatenumber]

Thanks for the thorough investigation @LangLangBart

Glad it's not an issue with tsx. But we should fix the nightly error:

All version numbers passed to esbuild must be in the format "X", "X.Y", or "X.Y.Z ... Invalid version: "21.0.0-nightly202304287ae1360358""

[LangLangBart]

Thanks for the thorough investigation @LangLangBart

😀

---

@privatenumber

• related issue in evanw/esbuild about node nightly versions
  • Transform fails when using a nightly build of Node evanw/esbuild#2766
• seems to be intentional

[felladrin]

Hey there! I just wanted to let you know that this issue has been resolved in Node v20.1.0 🎉