fix(fspy): tolerate torn shared-memory frames when collecting traced accesses

[wan9chi]

Motivation

Closes #544.

vp run can crash while collecting fspy path accesses after the task itself completed successfully. Issue 544's backtrace shows the shared-memory frame reader misparsing frame content as a frame header (1919954688 = 0x72702F00 is exactly "\0/pr" from an absolute path) and panicking on the resulting out-of-bounds skip. The same corruption class has an in-bounds variant the issue calls out explicitly: a misparsed frame that decodes into garbage PathAccess records — or fails to decode and panics the unwrap() on the same collection path. Either way the run aborts (or the cache silently ingests incomplete data) even though the task succeeded.

The live race window behind the misparse is nanoseconds wide (see the issue's fresh-relink correlation), so the e2e reproduction feeds the corruption through the channel's own public Sender API instead of racing: a well-formed frame whose content is not a decodable PathAccess. No direct shared-memory writes are involved; the helper connects a sender to the task's own channel exactly like any traced process does, via the payload fspy hands every traced process. The out-of-bounds misparse from the issue's backtrace cannot be produced quiescently by any API sequence (the writer stores the header before any content, and every claimed extent is covered by the end offset), so that arm is covered byte-exactly by unit tests instead.

Approach

Two commits, meant to be read in order:

1. test(e2e): reproduce fspy channel garbage-frame crash (#544) — adds a vtt write-garbage-fspy-frame helper and the fspy_garbage_frame e2e fixture, which runs such a task twice. The snapshot at this commit captures the crash-after-success (panic in iter_path_accesses, exit 101 on both runs). CI on this commit is green with the panic snapshot, demonstrating the bug is reproduced stably on every platform with the shared-memory channel (the fixture is skipped on musl, where the channel doesn't exist and fspy uses seccomp-unotify arenas instead).

2. fix(fspy): treat unreadable shm frames as truncated instead of panicking — makes the reader defensive, following the issue's suggestion:

   • ShmReader::iter_frames stops (instead of panicking) when a frame's recorded extent overruns the used region, and reports it via is_tail_truncated(); new shm_io unit tests craft the issue's exact byte state ("\0/pr" read as a 1.9 GB frame header) and assert the truncation;
   • a frame that fails to deserialize ends the iteration the same way instead of unwrap()-panicking;
   • the truncation propagates to update_cache, which skips caching with a new TrackingIncomplete reason — mirroring how FspyUnsupported degrades — because the inferred inputs/outputs may be missing entries and a cache entry built from them could produce stale hits;
   • the summary shows → Not cached: file access tracking data was incomplete.

   The e2e snapshot is updated to prove it: the run now exits 0 with the not-cached notice, and the second run stays a cache miss (nothing bogus was cached).

The root-cause audit of receiver-lock coverage (which descendants can write without holding the shared flock) and acquire-ordering for a non-quiescent reader remain follow-up work per the issue; this PR removes the crash and the unsound caching path regardless of which hypothesis produces the corrupted frame stream.

🤖 Generated with Claude Code

https://claude.ai/code/session_017ps7hxpYTqwk3t9qnPgyK8

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 43da79ec8d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".