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: #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.