Node.js Version
v24.19.0
NPM Version
11.17.0
Operating System
Linux 6.1.176-223.369.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jul 24 13:34:27 UTC 2026 x86_64 GNU/Linux
Subsystem
v8
Description
I suspect a regression in the latest release, but I don't think the information I've been able to gather is specific enough to write a bug in the Node project. I'm curious if anyone else is running into the same issue with this brand new release.
After updating from Node.js 24.18.1 to 24.19.0, with no changes to my application code or NPM libraries, my application began crashing sporadically with out-of-memory, only when under load. The crash occurred in a test environment after the application ran without problems for hours or (in some cases) as little as 2 minutes. I rolled back to the old build, keeping the same load profile, and the crashes stopped.
I'm using package-lock.json and npm ci, so I don't believe any dependencies changed at the same time I updated the Node.js version.
I'm using New Relic for monitoring, and I attached screenshots that I believe show there is no actual memory leak -- or at least not one that lasted long enough to span sampling intervals. (The break in the lines shows when the process crashed and was restarted by Docker.) The heap sizes in the screenshot are very different from the sizes in the Last few GCs from the console output I pasted below (~400 MB in the New Relic data vs 2034 MB in the OOM trace). The console output is from the same process as the New Relic screenshots.
I'm running in a Docker container from the image node:24-trixie-slim.
Here is the line in my Dockerfile showing the command line args:
CMD ["node", "--enable-source-maps", "--optimize-for-size", "server.js"]
I'm not setting --max-old-space-size. I'm using --optimize-for-size because we run several Docker containers on each instance, which sometimes do not have equal load, and we wanted to keep each process's memory usage low to avoid a case where the sum of all their memory usages was high enough to trigger alerts or worse.
Here are environment variables I'm setting:
GLIBC_TUNABLES=glibc.rtld.execstack=2 # required by some native code used by one of our dependencies
NODE_ENV=production
Some metrics from New Relic:
Minimal Reproduction
I cannot reproduce this issue consistently; I have seen it occur after hours or minutes running at load. I also can't share the proprietary code, so I hope my brief description provided enough clues.
The application is proprietary code and uses many WebSockets, polyfills for browser functionality, Axios HTTP requests, and a proprietary add-on with native code. (We are using Node.js to simulate web clients running code that normally runs in a browser, as a performance test of our server-side code.)
Output
<--- Last few GCs --->
[5919:0x24572000] 15150338 ms: Scavenge 2034.3 (2049.2) -> 2033.6 (2049.4) MB, pooled: 2 MB, 0.63 / 0.00 ms (average mu = 0.140, current mu = 0.000) allocation failure;
[5919:0x24572000] 15151703 ms: Mark-Compact 2034.5 (2049.4) -> 2033.8 (2049.9) MB, pooled: 2 MB, 1364.68 / 0.00 ms (average mu = 0.083, current mu = 0.005) allocation failure; scavenge might not succeed
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0x75356c node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
2: 0xc52cd0 [node]
3: 0xc52dbf [node]
4: 0xef6695 [node]
5: 0xef66c2 [node]
6: 0xef69ba [node]
7: 0xf076ba [node]
8: 0xf0ba60 [node]
9: 0x199e0d1 [node]
Before You Submit
Node.js Version
v24.19.0
NPM Version
11.17.0
Operating System
Linux 6.1.176-223.369.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jul 24 13:34:27 UTC 2026 x86_64 GNU/Linux
Subsystem
v8
Description
I suspect a regression in the latest release, but I don't think the information I've been able to gather is specific enough to write a bug in the Node project. I'm curious if anyone else is running into the same issue with this brand new release.
After updating from Node.js 24.18.1 to 24.19.0, with no changes to my application code or NPM libraries, my application began crashing sporadically with out-of-memory, only when under load. The crash occurred in a test environment after the application ran without problems for hours or (in some cases) as little as 2 minutes. I rolled back to the old build, keeping the same load profile, and the crashes stopped.
I'm using
package-lock.jsonandnpm ci, so I don't believe any dependencies changed at the same time I updated the Node.js version.I'm using New Relic for monitoring, and I attached screenshots that I believe show there is no actual memory leak -- or at least not one that lasted long enough to span sampling intervals. (The break in the lines shows when the process crashed and was restarted by Docker.) The heap sizes in the screenshot are very different from the sizes in the
Last few GCsfrom the console output I pasted below (~400 MB in the New Relic data vs 2034 MB in the OOM trace). The console output is from the same process as the New Relic screenshots.I'm running in a Docker container from the image
node:24-trixie-slim.Here is the line in my
Dockerfileshowing the command line args:I'm not setting
--max-old-space-size. I'm using--optimize-for-sizebecause we run several Docker containers on each instance, which sometimes do not have equal load, and we wanted to keep each process's memory usage low to avoid a case where the sum of all their memory usages was high enough to trigger alerts or worse.Here are environment variables I'm setting:
Some metrics from New Relic:
Minimal Reproduction
I cannot reproduce this issue consistently; I have seen it occur after hours or minutes running at load. I also can't share the proprietary code, so I hope my brief description provided enough clues.
The application is proprietary code and uses many WebSockets, polyfills for browser functionality, Axios HTTP requests, and a proprietary add-on with native code. (We are using Node.js to simulate web clients running code that normally runs in a browser, as a performance test of our server-side code.)
Output
Before You Submit