Node 23 - heap out of memory

[bricss]

Version

v23.0.0

Platform

Microsoft Windows NT 10.0.26100.0 x64

Subsystem

No response

What steps will reproduce the bug?

Source code cannot be provided

How often does it reproduce? Is there a required condition?

Reproduced all the time

What is the expected behavior? Why is that the expected behavior?

Application have to run

What do you see instead?

<--- Last few GCs --->

[25912:000001E1029B5000]   105733 ms: Mark-Compact 15953.4 (24147.2) -> 9964.4 (26350.7) MB, pooled: 0 MB, 28618.29 / 0.00 ms  (average mu = 0.437, current mu = 0.349) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 00007FF62F6E25DB node::SetCppgcReference+15707
 2: 00007FF62F64B7F8 DSA_meth_get_flags+98136
 3: 00007FF63034CF71 v8::Isolate::ReportExternalAllocationLimitReached+65
 4: 00007FF6303397B6 v8::Function::Experimental_IsNopFunction+2710
 5: 00007FF630170680 v8::internal::StrongRootAllocatorBase::StrongRootAllocatorBase+34016
 6: 00007FF63016D3DD v8::internal::StrongRootAllocatorBase::StrongRootAllocatorBase+21053
 7: 00007FF630182C76 v8::Isolate::GetHeapProfiler+8150
 8: 00007FF630182DAE v8::Isolate::GetHeapProfiler+8462
 9: 00007FF630193CF7 v8::Isolate::GetHeapProfiler+77911
10: 00007FF62FE3BC8B v8::internal::Version::GetString+447755
11: 00007FF63040B824 v8::PropertyDescriptor::writable+738884
12: 00007FF63040BE96 v8::PropertyDescriptor::writable+740534
13: 00007FF5E812D91B

Process finished with exit code 134

Additional information

Using --max-old-space-size=8192 in NODE_OPTIONS didn't help 😣

[cedx]

Same issue here 😢 (also using Windows 10)

[mcollina]

Thanks for reporting!

Can you provide steps to reproduce? We often need a reproducible example, e.g. some code that allows someone else to recreate your problem by just copying and pasting it. If it involves more than a couple of different file, create a new repository on GitHub and add a link to that.

[cedx]

For my part, I managed to locate the source of my error: it comes from the execa package when the preferLocal option is enabled.

import {execa} from "execa"; // Installed: v9.4.1
const $ = execa({preferLocal: true, stdio: "inherit"});
await $`node --version`;
// Error... but OK when `preferLocal` is `false`.

I guess I'll just have to open a ticket on the execa repository. (Done => sindresorhus/execa#1161)

[bricss]

In my case I'm afraid it will be almost impossible to locate the source of the error. We have a massive back-end with plenty of packages and I even don't know where to start looking for the root cause. But I have an idea that issue might be related to that one bug: https://github.com/nodejs/node/pull/55414

[avivkeller]

@cedx I can't reproduce the issue @bricss

I'm afraid it will be almost impossible to locate the source of the error

~~Then it will be "almost impossible" to fix. Without knowing what caused the error, it's impossible to know how to fix it.~~

~~Until a miminal reproducible example is provided, this issue isn't actionable.~~

Edit: I'd like to apologies for this. I was unaware that this was reproducible on other machines. Additionally, I should not have closed the issue as "impossible" to fix.

[legendecas]

This can be reproduced with @cedx's snippet on Windows.

The issue on this is path.resolve('D:\\', '..') returns D:, rather than D:\\ on Windows. This causes indefinite loop on https://github.com/sindresorhus/unicorn-magic/blob/main/node.js#L16-L29.

[avivkeller]

Ahh, it must be specific to windows (at least in this case), as I couldn't reproduce on Linux, my apologies for jumping to conclusions.

If that's the case, this is resolved by #55414, and may be a duplicate of #55410

[bricss]

The issue was fixed in the new version of Node 23.1.0 🩹

[cedx]

Also OK on my side with v23.1.0 👍