Fatal error when creating an array too large

[rotu]

Version

v24.11.1

Platform

Microsoft Windows NT 10.0.26100.0 x64

Subsystem

No response

What steps will reproduce the bug?

Array.from({length:2**27})

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

Every time.

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

I expect a nonfatal error. This is what happens when trying to create an array only slightly over the size limit:

> Array.from({length:2**26+1})
Uncaught RangeError: Invalid array length
    at Array.from (<anonymous>)

What do you see instead?

> Array.from({length:2**27})
<--- Last few GCs --->

[32936:000001652B9E2000]   127749 ms: Scavenge 1029.2 (1158.1) -> 1028.9 (1158.1) MB, pooled: 0 MB, 98.70 / 0.00 ms  (average mu = 0.990, current mu = 0.902) allocation failure;
[32936:000001652B9E2000]   129590 ms: Scavenge 1412.7 (1541.9) -> 1220.8 (1350.1) MB, pooled: 0 MB, 55.04 / 0.00 ms  (average mu = 0.990, current mu = 0.902) allocation failure;

FATAL ERROR: invalid table size Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 00007FF7348897FF node::OnFatalError+1343
 2: 00007FF7354CDA77 v8::Function::NewInstance+423
 3: 00007FF7352CE327 v8::base::AddressSpaceReservation::AddressSpaceReservation+322071
 4: 00007FF734FE9B6E v8::RegExp::GetFlags+69822
 5: 00007FF734FEA2C1 v8::RegExp::GetFlags+71697
 6: 00007FF7350FF298 v8::TypecheckWitness::TypecheckWitness+184456
 7: 00007FF7350FDF46 v8::TypecheckWitness::TypecheckWitness+179510
 8: 00007FF7350820CE v8::RegExp::GetFlags+693790
 9: 00007FF734FF8217 v8::RegExp::GetFlags+128871
10: 00007FF735074FCB v8::RegExp::GetFlags+640283
11: 00007FF73507575B v8::RegExp::GetFlags+642219
12: 00007FF735070C82 v8::RegExp::GetFlags+623058
13: 00007FF734EBE129 v8::String::Utf8Value::~Utf8Value+112121
14: 000001656393733A

Additional information

Related to #58197.
Reproducible in Node 25.2.0, by doubling the lengths in the above examples.

[juanarbol]

Yeah, I think this could be considered as a dupe of #58197, as it gets fixed, will fix this one as well. For that, I'm closing this issue.

Thanks for the report.

[rotu]

Yeah, I think this could be considered as a dupe of #58197, as it gets fixed, will fix this one as well.

It depends on the fix. Currently Array.from({length}) has varying behavior based on the value of length.

Below the limit: succeeds
Between the limit and 2**32-1: FATAL ERROR
Above 2**32: nonfatal error (RangeError)

So only if the limit is increased all the way to 2**32-1 does this issue get fixed as well.

[rotu]

You also get a similar fatal error with a briefer stack trace when trying to spread a large sparse array:

> [...Array(2**27-1)]

<--- Last few GCs --->

[9960:00000203B8350000]    18178 ms: Scavenge (interleaved) 659.6 (725.2) -> 595.6 (725.2) MB, pooled: 0 MB, 0.21 / 0.00 ms  (average mu = 0.960, current mu = 0.913) allocation failure;
[9960:00000203B8350000]    18240 ms: Scavenge (interleaved) 659.6 (725.2) -> 595.6 (725.2) MB, pooled: 0 MB, 0.23 / 0.00 ms  (average mu = 0.960, current mu = 0.913) allocation failure;

FATAL ERROR: invalid array length Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 00007FF6037497FF node::OnFatalError+1343
 2: 00007FF60438DA77 v8::Function::NewInstance+423
 3: 00007FF60418E327 v8::base::AddressSpaceReservation::AddressSpaceReservation+322071
 4: 00007FF603D83DDE v8::String::Utf8Value::~Utf8Value+135854
 5: 00000203F09B733A

[targos]

These can be reproduced in Chrome, so there's not much point in keeping an issue open in this repo (it's up to V8)

[rotu]

@targos Thanks - you're right. I reported this upstream at https://issues.chromium.org/issues/460650216