Perry crashes silently when Buffer.readInt32BE is called in a loop past ~250k-300k iterations

[proggeramlug]

Summary

A tight loop calling buf.readInt32BE(i*4) completes normally up to ~250k iterations, then crashes silently (no output, no error message) somewhere between 250k and 300k iterations. Exit code propagates as 0 through shell pipes, making this very easy to miss.

Discovered while benchmarking #92 — trivial to reproduce on main at v0.5.179.

Repro

```ts
console.log('N=' + process.argv[2]);
const N = parseInt(process.argv[2] || '100000');
const buf = Buffer.alloc(N * 4);
console.log('alloc ok, len=' + buf.length);
for (let i = 0; i < N; i++) buf.writeInt32BE(i * 37, i * 4);
console.log('fill ok');
let sum = 0;
for (let i = 0; i < N; i++) sum += buf.readInt32BE(i * 4);
console.log('read ok, sum=' + (sum & 0xFFFF));
```

```
$ perry compile bench92_crash.ts -o bench92_crash && for n in 100000 200000 250000 300000 500000 1000000; do echo "--- N=$n ---"; ./bench92_crash $n; done
--- N=100000 ---
N=100000
alloc ok, len=400000
fill ok
read ok, sum=49008
--- N=200000 ---
N=200000
alloc ok, len=800000
fill ok
read ok, sum=29408
--- N=250000 ---
N=250000
alloc ok, len=1000000
fill ok
read ok, sum=18456
--- N=300000 ---
N=300000
alloc ok, len=1200000
fill ok # <-- no "read ok" line; process exits silently
--- N=500000 ---
N=500000
alloc ok, len=2000000
fill ok # <-- same silent failure
--- N=1000000 ---
N=1000000
alloc ok, len=4000000
# <-- crashes even during the fill loop now
```

Node and Bun complete all sizes in single-digit ms.

What seems to be happening

• Buffer.alloc is fine up to at least 4MB (1M × 4) — the header prints.
• writeInt32BE fill loop crashes only at very large sizes (N=1M visible).
• readInt32BE read loop threshold is ~250k iterations: works at 250k, fails at 300k. The threshold appears iteration-count dependent, not buffer-size dependent (N=300k and N=500k both silently stop after `fill ok`, which is the same number of writeInt32BE iterations that worked at N=500k — so it's something about the 300k-ish `readInt32BE` call count, not the buffer size).

Plausible causes to investigate:

• GC triggering mid-loop and corrupting something (Mark-sweep GC has an arena block allocation threshold)
• Arena bounds being exceeded
• A counter wrap or signed-overflow in the read path
• Exit code not propagated because the crash is after a flushed `console.log` — SIGKILL or process::exit(0) somewhere silently

Impact

This crash currently blocks accurate benchmarking of #92 (bulk decode throughput). Any measurement past ~250k Buffer reads hits this instead of measuring the primitive cost.

Also potentially affects any Perry app doing bulk Buffer work — large Postgres result sets, file-to-buffer processing, binary codecs. The silent-exit-0 shape is the worst possible failure mode.

Environment

• Perry 0.5.179
• macOS arm64 (Apple Silicon)

Related: #92 (bulk decode perf).

[proggeramlug]

Investigation findings

Reproduction

Using the repro script from the issue description (compiled with cargo run --release -- /tmp/bench92_crash.ts -o /tmp/bench92_crash):

N	Result
100,000	exit 0 ✓
200,000	exit 0 ✓
250,000	exit 0 ✓ (barely)
300,000	SIGSEGV (exit 139), crash after "fill ok"
500,000	SIGSEGV (exit 139), crash after "fill ok"
1,000,000	SIGSEGV (exit 139), crash before "fill ok"

Bisect result: iteration-count dependent, not buffer-size dependent. The crash point is ~200k–300k for the read loop (1 arg per call → 16 bytes/iteration), and ~500k for the write loop (2 args per call → 16 bytes/iteration for the larger [2 x double] alloca).

Stack trace (gdb)

#0  0x00007ffff7e34ee0 in js_buffer_read_int32_be ()
#1  0x00007ffff7e4a2c0 in dispatch_buffer_method ()
#2  0x00007ffff7e3f110 in js_native_call_method ()
#3  0x0000555555566890 in ?? ()    ← module init / main loop function

Frame #3 (info frame):

frame at 0x7fffffffe100
called frame at 0x7fffff7ff150
saved rip = ...

Frame #3 consumed 0x7fffffffe100 − 0x7fffff7ff150 = 8,384,432 bytes ≈ 8.2 MB — the entire 8 MB stack limit — from a single compiled TypeScript function.

Root cause

Non-entry-block alloca in crates/perry-codegen/src/lower_call.rs around line 1566.

When Perry lowers a dynamic method call that goes through js_native_call_method (the "native call" path, used for buf.readInt32BE(...), buf.writeInt32BE(...), and other methods not statically typed at codegen time), it needs to marshal the JS arguments into a [N x double] stack array to pass as (args_ptr, args_len). The relevant code:

// lower_call.rs ~1563–1573
let n = lowered_args.len();
let buf_reg = blk.next_reg();
// BUG: emits alloca in the *current* basic block (the loop body), not the entry block
blk.emit_raw(format!("{} = alloca [{} x double]", buf_reg, n));
for (i, v) in lowered_args.iter().enumerate() {
    let slot = blk.gep(DOUBLE, &buf_reg, &[(I64, &format!("{}", i))]);
    blk.store(DOUBLE, v, &slot);
}

blk.emit_raw(...) appends the alloca to whatever basic block blk currently represents — which, when the call site is inside a loop, is the loop-body block. LLVM compiles a non-entry-block alloca as a runtime sub %rsp, N executed on every pass through that block, with no corresponding add %rsp, N to restore it:

; disassembly of the readInt32BE loop body (N=300k run):
0x555555566877:  mov  %rsp,%rax
0x55555556687a:  lea  -0x10(%rax),%rdx   ; new_rsp = rsp - 16
0x55555556687e:  mov  %rdx,%rsp          ; ← permanent per-iteration stack growth
0x555555566881:  vmovsd %xmm0,-0x10(%rax)
...
0x5555555668cc:  ja   0x555555566860     ; loop back — rsp never restored

The math checks out exactly:

• Stack limit: 8,192 KB
• writeInt32BE loop: 2 args → 16-byte alloca × N iterations
• readInt32BE loop: 1 arg → 16-byte alloca × N iterations (16-byte alignment)
• N=250k: (250k + 250k) × 16 = 8,000,000 bytes < 8 MB → survives (barely)
• N=300k: fill uses 4,800,000 bytes; ~3.4 MB remain, sustaining ~212k read iterations → SIGSEGV ✓
• N=1M: fill loop exhausts the stack at ~512k iterations → SIGSEGV before "fill ok" ✓

This affects all dynamic method call sites that reach js_native_call_method, not just Buffer — any method call Perry can't statically resolve at codegen time, inside a hot loop, will exhibit the same stack-eating behavior.

Proposed fix

Perry's codebase already has the correct API for this: LlFunction::alloca_entry in crates/perry-codegen/src/function.rs (~line 113):

/// Allocates a slot in the **function entry block** — the LLVM-conventional
/// place for all alloca instructions, ensuring the slot is in scope from
/// every reachable basic block.
pub fn alloca_entry(&mut self, ty: LlvmType) -> String {
    let r = format!("%r{}", self.reg_counter.next());
    self.entry_allocas.push(format!("  {} = alloca {}", r, ty));
    r
}

This pattern is already used correctly elsewhere in lower_call.rs (e.g. lines ~1995, ~2020, ~2270).

The fix is to replace the blk.emit_raw(alloca ...) at lower_call.rs:1566 with a hoisted entry-block alloca. Since alloca_entry currently only handles scalar types, the simplest approach is either:

1. Add an alloca_entry_array(elem_ty: LlvmType, n: usize) -> String variant on LlFunction, or
2. Allocate n individual double slots via alloca_entry and address them by offset (matches what blk.gep already does).

The change is small — roughly 5–10 LOC in lower_call.rs plus a 4-line helper on LlFunction if option 1 is chosen. Risk is low: it's a mechanical substitution of one alloca emission for another, and the pointer value returned is used identically (as args_ptr to js_native_call_method). The fix resolves the crash for all loop depths and all call-arg counts simultaneously.

Scope estimate

• crates/perry-codegen/src/lower_call.rs: ~5–8 lines changed (the blk.emit_raw + surrounding block)
• crates/perry-codegen/src/function.rs: ~4 lines added (optional array-alloca helper)
• Test: the repro script with N=500k or N=1M serves as a regression test

---

Generated by Claude Code