Allocation-failure paths abort with panic! rather than surfacing a catchable JS error:
- User-controlled-length (tractable, worth fixing):
crates/perry-runtime/src/typedarray/mod.rs:535, crates/perry-runtime/src/buffer/header.rs:534, crates/perry-runtime/src/regex.rs:388, set.rs:566, map.rs:607.
- Foundational (large blast radius, likely not worth it):
crates/perry-runtime/src/gc/malloc.rs:150 and crates/perry-runtime/src/arena/block.rs:56 route every allocation and would need a runtime-wide error-propagation refactor (L effort, HIGH risk).
Impact: new Uint8Array(1e15) (and similar user-controlled sizes) aborts the process instead of throwing RangeError: Invalid array length / allocation error. Note that genuine OOM recovery is hard and many engines also abort — so the realistic scope is the user-controlled-length constructors, not the foundational allocator.
Proposed fix (scoped): In the TypedArray/Buffer/RegExp/Set/Map constructors, validate requested size and throw a catchable RangeError when the backing allocation cannot be satisfied, leaving the object in a consistent state. Explicitly defer the gc_malloc/arena refactor.
Acceptance: Constructing an over-large typed array/buffer throws a catchable error; gc_malloc/arena scope documented as out-of-scope.
Allocation-failure paths abort with
panic!rather than surfacing a catchable JS error:crates/perry-runtime/src/typedarray/mod.rs:535,crates/perry-runtime/src/buffer/header.rs:534,crates/perry-runtime/src/regex.rs:388,set.rs:566,map.rs:607.crates/perry-runtime/src/gc/malloc.rs:150andcrates/perry-runtime/src/arena/block.rs:56route every allocation and would need a runtime-wide error-propagation refactor (L effort, HIGH risk).Impact:
new Uint8Array(1e15)(and similar user-controlled sizes) aborts the process instead of throwingRangeError: Invalid array length/ allocation error. Note that genuine OOM recovery is hard and many engines also abort — so the realistic scope is the user-controlled-length constructors, not the foundational allocator.Proposed fix (scoped): In the TypedArray/Buffer/RegExp/Set/Map constructors, validate requested size and throw a catchable
RangeErrorwhen the backing allocation cannot be satisfied, leaving the object in a consistent state. Explicitly defer thegc_malloc/arena refactor.Acceptance: Constructing an over-large typed array/buffer throws a catchable error;
gc_malloc/arena scope documented as out-of-scope.