SIGTRAP crash when a program mixes Buffer-typed and Uint8Array-typed function parameters

[proggeramlug]

Summary

A program that defines two functions — one taking a `Buffer` parameter, one taking a `Uint8Array` parameter — and invokes them in sequence on the same underlying buffer crashes with SIGTRAP (exit 133) in the second call. The same functions in isolation both work correctly. Reproducible on current `main` with zero local changes applied.

Discovered while extending the #92 / #166 buffer-read intrinsic to cover Buffer-typed params. Blocks extending the extension to Uint8Array-typed params (both shapes are identical from the intrinsic's perspective), so this issue gates that follow-up work.

Repro (crashes on main at v0.5.179)

```ts
const big = Buffer.alloc(1024);
for (let i = 0; i < 256; i++) big.writeInt32BE(i * 37, i * 4);

function sumRow(row: Buffer, n: number): number {
let s = 0;
for (let i = 0; i < n; i++) s += row.readInt32BE(i * 4);
return s;
}
console.log('param sum:', sumRow(big, 256)); // prints 1207680 correctly

function firstBytes(arr: Uint8Array): number {
return arr[0] + arr[1] + arr[2] + arr[3];
}
console.log('u8 param:', firstBytes(big)); // crashes
```

```
$ perry compile repro.ts -o repro && ./repro
param sum: 1207680
; exit: 133
```

Node and Bun both complete normally and print `u8 param: 0`.

Bisect

Each call works in isolation — removing either function eliminates the crash:

Scenario	Result
`firstBytes(big)` alone	✅ prints 0
`sumRow(big, 256)` alone	✅ prints 1207680
Both, `firstBytes` first	(untested — may not crash)
Both, `sumRow` first	❌ SIGTRAP in `firstBytes`

Tried disabling the #166 Buffer-read intrinsic entirely at the codegen level (`try_emit_buffer_read_intrinsic` forced to return `None`): crash still happens. So the intrinsic is not the cause; this is a pre-existing bug in the interaction between the two param shapes.

Crash signal

`lldb` shows the program stops on `brk #0x1` — an ARM64 instruction LLVM emits as a `noreturn` marker after a call-to-panic. So some Perry runtime helper is calling a panic/abort function inside `firstBytes`. Without debug symbols it's hard to tell which helper, but the likely candidates:

• Runtime NaN-box unbox assertions (`unbox_buffer_ptr` / `unbox_uint8array_ptr`)
• GC write-barrier or arena-bounds assertion
• A type-check failure on the Uint8Array receiver

Worth running with `PERRY_DEBUG_SYMBOLS=1` and a fresh lldb to localize.

Fix direction

Unknown without further investigation — this isn't my area. Possible angles:

• Some per-function state in codegen is leaking across function boundaries and causing the second function to look up a stale slot
• The Uint8Array fast path at `expr.rs:4685-4699` has a latent issue that only surfaces after a Buffer fast path in the same compilation
• A runtime registry is getting corrupted by the first call's arena operations

Impact

• Any program that has both `Buffer` and `Uint8Array` parameter shapes will crash when they're invoked in sequence. Not a hypothetical — happens on the natural Postgres-driver shape where one function accepts the raw network buffer and another accepts a derived slice.
• Blocks generalizing the fix(codegen): #92 intrinsify Buffer numeric reads (5x speedup on readInt32BE hot loop) #166 param-intrinsic to Uint8Array params (which is why I ran into this).

Related

• Bulk decode throughput: 2-3× slower than V8/JSC on primitives used in the Postgres driver hot path #92 (bulk decode perf — work in progress)
• fix(codegen): #92 intrinsify Buffer numeric reads (5x speedup on readInt32BE hot loop) #166 (Buffer-read intrinsic — discovered this while extending)

Environment

• Perry 0.5.179 on macOS arm64 (also reproducible on `main` at commit 6e57861)

[proggeramlug]

Investigation findings

Reproduced and root-caused on current main. Summary first, then full details.

TL;DR — the crash is not a Buffer/Uint8Array runtime bug, not a GC issue, and not from the #166 intrinsic. It is a missing match arm in the transform inliner's substitute_locals function (crates/perry-transform/src/inline.rs). The inliner correctly identifies firstBytes as a pure, inlinable function and inlines its body into the module init — but the parameter substitution walk doesn't recurse into Expr::Uint8ArrayGet, leaving a stale LocalGet(param_id) in the inlined code. The codegen's soft fallback for that unknown LocalId returns TAG_UNDEFINED, which after unboxing is address 1, which makes safe_load_i32_from_ptr return length 0, which makes @llvm.assume(i1 false) fire — undefined behaviour that LLVM converts to a trap.

---

1. Exact crash location

The brk #0x1 (ARM64) / SIGSEGV (Linux x86-64) is reached via @llvm.assume(i1 false) in the module init function, not inside firstBytes at all. It is produced by the UB-on-assume path in the Uint8ArrayGet slow path (crates/perry-codegen/src/expr.rs:4706-4708):

let in_bounds = blk.icmp_ult(I32, &idx_i32, &len_i32);
blk.emit_raw(format!("call void @llvm.assume(i1 {})", in_bounds));

When len_i32 is 0 and idx_i32 is 0, in_bounds = false, and LLVM converts @llvm.assume(i1 false) into unreachable → brk #0x1/segfault. This is not a runtime Rust panic.

---

2. Root cause — missing arm in substitute_locals

File: crates/perry-transform/src/inline.rs

The transform pass (inline_functions) runs before codegen. It identifies functions as inlinable (≤10 stmts, no captures, no super calls, no closures over params) and as pure (body only references own params/body locals). firstBytes passes both checks — it's a single-Return function with no side effects.

When inlining firstBytes(big) into the module init, try_inline_simple_call builds:

param_map = { arr_id → LocalGet(big_id) }   // arr_id=6 when sumRow is present, =2 standalone

then calls substitute_locals(&mut result, &param_map, ...) on the cloned return expression Binary { ..., Uint8ArrayGet { array: LocalGet(arr_id), index: Integer(0) }, ... }.

The bug: substitute_locals is a large match-on-Expr that recurses into subexpressions. It handles Expr::IndexGet, Expr::BufferIndexGet, and dozens of other variants — but Expr::Uint8ArrayGet { array, index } and Expr::Uint8ArraySet { array, index, value } are absent. They fall through to the _ => {} catch-all at the bottom (line 1763), which does nothing.

Result: after "substitution", the inlined expression still contains LocalGet(arr_id) where LocalGet(big_id) should be.

---

3. What the codegen does with the stale LocalId

In the module init codegen context:

• ctx.locals = {0: big_slot, 1: i_slot} (module-init locals only)
• ctx.module_globals = {0: "big_global"}
• arr_id (=6 in combined repro, =2 in standalone) is in neither

The LocalGet(arr_id) lowering at expr.rs:702–720 falls all the way to the soft fallback which returns the constant TAG_UNDEFINED = 0x7FFC_0000_0000_0001 (as a double literal). This is codegen-correct in the sense that it doesn't ICE, but it is semantically wrong.

The subsequent slow-path for Uint8ArrayGet then:

1. unbox_to_i64(TAG_UNDEFINED) → and i64 0x7FFC000000000001, 0x0000FFFFFFFFFFFF = 1
2. safe_load_i32_from_ptr(1) → icmp ult i64 1, 4096 = true → selects @perry_null_guard_zero → loads 0 for len
3. icmp ult i32 0, 0 = false
4. call void @llvm.assume(i1 false) → UB → LLVM marks block unreachable → trap

---

4. Bisect confirmation (Linux x86-64, built from current main)

I reproduced all cases:

Scenario	--print-hir inlined LocalGet	Result
Both functions, sumRow first (original repro)	LocalGet(6) in module init	❌ crash (SIGSEGV/SIGTRAP)
Both functions, firstBytes first (reversed)	LocalGet(2) in module init	❌ crash
firstBytes alone	LocalGet(2) in module init	❌ crash on Linux; reporter saw ✅ on macOS ARM64
Both params Buffer (no Uint8Array)	firstBytes uses BufferIndexGet, not Uint8ArrayGet	needs test

The macOS "firstBytes alone → prints 0" divergence is explained by LLVM optimization: in the simpler module LLVM may not fully constant-fold the assume chain before emitting machine code. On Linux x86-64, the constant TAG_UNDEFINED → unbox(1) → len=0 → assume(false) chain is fully folded in all cases and always crashes.

The --print-hir output for both the combined and standalone cases confirms the substitution failure:

# combined repro: firstBytes param arr = id 6, big = id 0
Init stmt [3]: ... Uint8ArrayGet { array: LocalGet(6), ... }
#                                              ^^ should be LocalGet(0)

# standalone: firstBytes param arr = id 2, big = id 0
Init stmt [2]: ... Uint8ArrayGet { array: LocalGet(2), ... }
#                                              ^^ should be LocalGet(0)

The "sumRow first" ordering matters on macOS because sumRow's presence increases module complexity, causing LLVM to fold the assume more aggressively. On Linux it's irrelevant — both orderings crash.

---

5. Proposed fix direction

Primary fix — add two match arms to substitute_locals in crates/perry-transform/src/inline.rs:

Expr::Uint8ArrayGet { array, index } => {
    substitute_locals(array, param_map, next_local_id);
    substitute_locals(index, param_map, next_local_id);
}
Expr::Uint8ArraySet { array, index, value } => {
    substitute_locals(array, param_map, next_local_id);
    substitute_locals(index, param_map, next_local_id);
    substitute_locals(value, param_map, next_local_id);
}

Expr::Uint8ArrayLength(arr) is the same pattern and should get an arm too:

Expr::Uint8ArrayLength(arr) => {
    substitute_locals(arr, param_map, next_local_id);
}

Secondary fix — the same three variants are also absent from inline_calls_in_expr's recursion match (the function that recurses into sub-expressions to find nested inlinable calls). They fall to _ => {} there too, meaning a call nested inside a Uint8ArrayGet index expression (e.g., buf[clamp(i)]) won't be inlined. This is a missed optimization, not a correctness bug, but worth fixing in the same PR.

Also worth auditing: find_max_local_id's check_expr — if Uint8ArrayGet is not listed there, the module-wide max-LocalId scan might undercount, potentially causing fresh inliner IDs to collide with existing ones in programs that use Uint8ArrayGet deeply nested.

No runtime changes needed. The bug is entirely in the HIR transform pass. The codegen's slow path for Uint8ArrayGet (expr.rs:4701–4715) is correct; it just receives garbage input because the inliner's substitution is broken.

---

6. Does this block #166's Uint8Array-param extension?

Yes, for inlinable functions. Any function that:

1. has a Uint8Array (or Buffer) typed parameter,
2. accesses it via arr[i] (which HIR lowers to Uint8ArrayGet),
3. is small enough to be inlined (≤10 stmts, pure, no captures), AND
4. is called from module-init scope (top-level console.log(firstBytes(big)) etc.)

...will produce the same stale-LocalGet bug after inlining. The fix in substitute_locals is a prerequisite for the #166 extension to be safe for all call sites.

For non-inlinable functions (e.g., sumRow with its runtime call inside the loop), the bug doesn't apply — the Uint8Array-param parameter is correctly accessed via the slow path inside the function's own codegen context where arr_id IS in ctx.locals. So the extension can land for non-inlinable shapes immediately; inlinable shapes need this fix first.

---

Generated by Claude Code