fix(tests): cap bounded-child RSS instead of address space

[chaliy]

What changed

awk_field_depth_bounded's supervised-child launcher no longer caps the child's
address space. Memory containment moves to a parent-side peak-RSS watchdog that
samples the live child, kills it on breach, and asserts the peak afterwards, so
growth still fails closed. CPU, stack, core, output-drain and wall bounds are
unchanged.

A static scan test now fails any test launcher that reintroduces an
address-space cap, in either the shell spellings (ulimit -v, ulimit -d) or a
direct setrlimit (RLIMIT_AS, RLIMIT_DATA), with an escape hatch
(// rlimit-as-ok: <reason>) for a launcher that provably never builds with a
sanitizer.

Why

The nightly AddressSanitizer job went red on run 257 while required CI stayed
green on the same commit (fa2262d). The launcher set ulimit -v 2097152;
AddressSanitizer reserves ~14 TiB of virtual address space for its shadow map
during startup, so the instrumented child died in ReserveShadowMemoryRange
before executing a line of test code. The test then failed on the launcher's own
cap rather than on the depth bound it asserts — the same divergence shape as the
CLI-path bug in run 252, and awk_field_depth_tests.rs was the only harness
still using an address-space cap.

RSS is also the better proxy for the runaway allocation the bound exists to
catch, and it costs nothing in virtual space, so one mechanism holds on
instrumented and native builds alike.

Before / After

Root cause, reproduced standalone (the failure is in ASAN startup, independent of
bashkit code):

$ gcc -fsanitize=address -o t t.c   # int main(void){return 0;}
$ /bin/sh -c 'ulimit -t 10 && ulimit -s 8192 && ulimit -c 0 && ulimit -v 2097152 && exec "$@"' x ./t
==524==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
==524==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
exit=134

$ /bin/sh -c 'ulimit -t 10 && ulimit -s 8192 && ulimit -c 0 && exec "$@"' x ./t
exit=0

The reservation size 0xdfff0001000 is byte-identical to the one in the nightly
log, confirming the same mechanism.

Before, under the real nightly invocation (-Z build-std, -Z sanitizer=address):

thread 'awk_field_depth_tests::awk_field_depth_bounded' panicked at
  crates/bashkit/tests/integration/awk_field_depth_tests.rs:82:5:
child status exit status: 1: ==15767==ERROR: AddressSanitizer failed to allocate
  0xdfff0001000 (15392894357504) bytes ...
test result: FAILED. 2409 passed; 1 failed

After, same invocation and flags on this branch:

$ RUSTFLAGS="-Z sanitizer=address" ASAN_OPTIONS="detect_stack_use_after_return=1:detect_leaks=0" \
  cargo +nightly test -Z build-std --target x86_64-unknown-linux-gnu \
  -p bashkit --test integration awk_field_depth -- --test-threads=1
test awk_field_depth_tests::awk_field_depth_bounded ... ok
test awk_field_depth_tests::awk_field_depth_child ... ok
test awk_field_depth_tests::finite_field_operands_match_gawk ... ok
test result: ok. 3 passed; 0 failed

The replacement bound is not vacuous: the child's measured peak RSS is 29,216 KiB
over ~4 polls in a 45 ms lifetime, against the 2 GiB ceiling (the same 2 GiB
figure as the old cap, now measured on resident rather than virtual memory), so
an ASAN build fits comfortably while multi-gigabyte growth still trips it.

Guard verified by mutation — reintroducing the cap fails the scan with the
offending line:

address-space caps break sanitizer-instrumented children; cap RSS from the parent
instead (knowledge/operations/testing.md):
crates/bashkit/tests/integration/awk_field_depth_tests.rs:82: let limits = "... ulimit -v 2097152 ..."

Risk

• Low. Test-harness only; no production code changes.
• The child keeps its CPU, stack, core, output-drain and wall bounds, and gains
  an RSS bound it did not have. The removed cap is the one that could not
  coexist with a sanitizer.
• Residual: RSS is sampled on a 10 ms poll, so an allocation spike that both
  starts and ends between two polls is unmeasured. status.success(), the stack
  and CPU limits and the wall watchdog still fail such a run, and the depth guard
  under test is what bounds the recursion in the first place.

Checklist

• Tests added or updated
• Backward compatibility considered (internal test harness)

https://claude.ai/code/session_013mA6kgZvfp234w1L2gLint

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	dd6bea0	Commit Preview URL Branch Preview URL	Oct 12 2026, 09:21 AM