Symptom
The extended_checks "Test ser/deser" step SIGSEGV'd on linux (exit 139, CRASH: SIGSEGV ... at address 0x7c5) on PR #3450's first run (job), during the --deser pass. A plain re-run of the same lane on the same commit passed, and the sweep is green on darwin/windows — no reproduction since.
What was ruled out (bisect findings)
The crash log's adjacent reading past the end of stream output initially looked like the defect — it is not. A full directory/file bisect attributes those prints to tests/live_host/test_live_vars.das's deliberate "garbage data does not crash with try/recover" arm: it feeds 2 garbage bytes to daslib/archive's reader inside try/recover, and archive.das:69 logs the message (twice — once per failed serialize) and continues by design. Every green CI interp sweep prints the same lines; the deser pass on macOS prints them and passes 12/12. Red herring.
With that excluded there is no deterministic repro: full-tree --ser/--deser round-trips are clean on macOS (master f79afc588 and #3450's branch), and the linux lane passed on re-run. What remains is a single core-dumped deserializer-sweep run on linux — either a genuine latent, layout-sensitive bug in the AST deserializer's execution of the ~1206-program stream (the crash site was in the vicinity of the live_host programs), or runner-infra flake.
Filing for the record so a second occurrence has a trail; nothing actionable until it reproduces. If it fires again, the useful artifacts are: which program index the deser loop was on (Deserializing N programs... progress), and a core/backtrace from the runner.
Symptom
The extended_checks "Test ser/deser" step SIGSEGV'd on linux (exit 139,
CRASH: SIGSEGV ... at address 0x7c5) on PR #3450's first run (job), during the--deserpass. A plain re-run of the same lane on the same commit passed, and the sweep is green on darwin/windows — no reproduction since.What was ruled out (bisect findings)
The crash log's adjacent
reading past the end of streamoutput initially looked like the defect — it is not. A full directory/file bisect attributes those prints totests/live_host/test_live_vars.das's deliberate "garbage data does not crash with try/recover" arm: it feeds 2 garbage bytes todaslib/archive's reader insidetry/recover, andarchive.das:69logs the message (twice — once per failedserialize) and continues by design. Every green CI interp sweep prints the same lines; the deser pass on macOS prints them and passes 12/12. Red herring.With that excluded there is no deterministic repro: full-tree
--ser/--deserround-trips are clean on macOS (masterf79afc588and #3450's branch), and the linux lane passed on re-run. What remains is a single core-dumped deserializer-sweep run on linux — either a genuine latent, layout-sensitive bug in the AST deserializer's execution of the ~1206-program stream (the crash site was in the vicinity of the live_host programs), or runner-infra flake.Filing for the record so a second occurrence has a trail; nothing actionable until it reproduces. If it fires again, the useful artifacts are: which program index the deser loop was on (
Deserializing N programs...progress), and a core/backtrace from the runner.