fix: swallowed oom

[Gabriel-Trintinalia]

Split out of #99, which mixed two independent concerns. This is the allocation-failure half; #99 keeps the database-error half. Same principle, different source, reviewable separately.

Problem

Several call sites absorb an allocation failure and carry on with a degraded value. Each turns "out of memory" into "this block computed a different answer" — for a stateless prover the worst possible trade, since a wrong state root is indistinguishable from a consensus disagreement and far harder to diagnose.

site	swallowed into	count
bytecode/main.zig analyzeLegacy	an empty jump table — every JUMPDEST reads invalid	1
context/journal.zig	the EIP-7708 transfer log is dropped silently	2
interpreter/opcodes/host_ops.zig	LOG reports OOM as out-of-gas	1
precompile/*, crypto/backends/secp256r1.zig	OOM reported as PrecompileError.OutOfGas	22

The first is not hypothetical. In for_amsterdam_at_0060M, compute/precompile/identity::test_identity exhausts the ~490 MiB guest heap, then cannot allocate the 63-byte jump-dest bitmap for the EIP-7002 withdrawal contract during the post-block system call. The call halts on invalid_jump, becomes SystemContractCallFailed, and the block is rejected with a wrong root — naming the identity precompile and the 7002 contract, neither of which is at fault. Nothing in the output mentions memory. It took a full day to trace.

Change

These sites cannot propagate — their signatures are fixed by infallible callers. So they record on a channel and the block is rejected, in the same shape as #99's ctx_error. Recording rather than wrapping the allocator keeps the success path free of extra indirection.

Checks live in transitionWithContext, not in its callers: five call sites execute a block, and a caller that forgot would be silently wrong again. It resets on entry, checks at each transaction boundary (so a failed block stops rather than running to completion on degraded values), and gates once more before returning to cover the post-block system calls and BAL/requests hashing.

A boundary check rather than a per-instruction one: the interpreter loop is hot enough that checking there would cost trace cells on every block.

Why not make OOM fatal

Tried and abandoned. The guest has no working abort: @trap() does not halt because ZisK's op_halt() is unimplemented!(), so the panic handler logs, execution resumes, and the block loops printing execution failed: until the 2^36 step cap — a hang instead of a fast failure.

That is a pre-existing hazard for any guest panic (unreachable, out-of-bounds, overflow in ReleaseSafe), not something this PR introduces, and deserves its own issue.

Verification

• zig build test: 400/400. bytecode added to the test module list — tests there never ran, the same trap fix(stateless): audit of swallowed database errors that fabricate execution results #99 documents for context.
• Mutation-checked: dropping recordOom() from analyzeLegacy or from identity fails a test by name.
• On a block that genuinely exhausts the heap: execution failed: OutOfMemory, terminating cleanly, instead of a wrong root.

Two of the seven sites are proven by test (analyzeLegacy, the precompiles); the journal.zig and host_ops.zig sites were found by pattern and are fixed but not reproduced.

🤖 Generated with Claude Code

---

Note

High Risk
Touches consensus-visible execution paths (bytecode analysis, logs, precompiles) and block transition error handling; incorrect gating could reject valid blocks or still miss silent degradation.

Overview
Swallowed allocation failures on infallible EVM paths no longer produce silently wrong block results. A sticky process-global OOM channel (recordOom / oomSeen / resetOom) on zesu_allocator records failures where callers cannot propagate errors; the block driver rejects the block with OutOfMemory instead of finishing with a wrong state root or logs hash.

Recording sites include legacy jump-table analysis (empty table on alloc failure), EIP-7708 journal logs, LOG topic allocation in the interpreter, and precompile/crypto paths that still return OutOfGas locally but now also call recordOom. Gating lives in transitionWithContext: reset at block start, check at each transaction boundary, and a final check after post-block work.

Tests cover analyzeLegacy and identity precompile OOM recording; build.zig adds the bytecode module to zig build test so those tests actually run. zkVM allocator shims implement the same OOM API.

^{Reviewed by Cursor Bugbot for commit d83e322. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit d83e322. Configure here.}

[cursor]

EIP-7708 topics alloc still swallows OOM

High Severity

addEip7708TransferLog and addEip7708BurnLog record OOM only on the later data alloc. The earlier topics alloc still returns without recordOom(). Topics is the larger allocation, so heap exhaustion typically fails there first, the log is dropped, and the block can complete with a changed logsHash.

Additional Locations (1)

• src/evm/context/journal.zig#L1019-L1020

 

^{Reviewed by Cursor Bugbot for commit d83e322. Configure here.}

[cursor]

LOG data copy still reports OOG

High Severity

makeLogFn records OOM on the topics alloc but the following log-data dupe still halts as out-of-gas without recordOom(). LOG0 never takes the topics path, so its only allocation is this unrecorded copy. A transaction the reference completes can appear to OOG and the block can be accepted.

 

^{Reviewed by Cursor Bugbot for commit d83e322. Configure here.}