L17: receiverHosted lift (fix the amd64 ReleaseSafe SEGV before merge) - #9
Merged
Conversation
…erred-Release import pins" This reverts commit 51abe13.
The amd64 ReleaseSafe SEGV (CI 30606010609) was in the TEST, not the lift. The
Windows trace named it exactly:
deliverLocalException (mod.zig:3775)
forceCancelAllQuestions
Peer.deinit (mod.zig:2062)
ImportOwnerVat.deinitAll -> self.remote.deinit()
test.L17 site 2 ... -> defer vat.deinitAll()
`stageSite2Provision` deliberately drops the staged call's Return in flight (it
severs the link so the owner's resolved_answers entry stays live, which is the
whole point of the site-2 shape). That leaves the question OUTSTANDING until
`vat.remote.deinit()`, where `forceCancelAllQuestions` delivers a local
exception THROUGH the question's stored `ctx` pointer -- and that pointer was
`&call_probe`, a local of the helper, whose frame died when the helper
returned. `deliverLocalException` then writes into a vanished stack frame: a
segfault on amd64 Linux and Windows under ReleaseSafe, and on arm64 macOS a
silent scribble into a still-mapped page, which is why every local gate and the
arm64 tier passed.
Both probes now live in the test's frame and are passed in, so they outlive the
peer that cancels the question. The helper's doc comment says why, since the
next person will be tempted to tidy them back into it.
Only this helper has the shape: it is the one that deliberately leaves a
question unanswered, and exactly its two tests crashed while the site-1 and OOM
fixtures in the same run stayed green.
The lift's own accounting is untouched by this commit -- `git diff` covers the
test file only. Local gates pass, but they passed before too; amd64 CI on this
PR is the oracle that matters.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Re-applies f2e15aa (reverted from main as 51abe13 after CI run 30606010609 went red).
Blocker: two site-2 tests SEGV under ReleaseSafe on ubuntu-latest AND windows-latest (arm64 macOS passes):
L17 site 2: a stored .promised target re-resolving to an IMPORT is served with a serve-time pinL17 witness: a stored .promised target whose re-resolved import has DIED still fails closed, by namepreceded by repeated
promise-held release for unknown export id=2warnings. Likely a stale pointer in the serve-time pin /.promisedre-resolution path that only optimized amd64 layout exposes.Diagnosis leads: the serve-time pin for site 2 is taken on the RE-RESOLVED import at Accept time and held by the proxy ctx; check the window between re-resolution and ctx creation, and the DIED-import witness path where the entry is gone but something still walks it. The
unknown export id=2warnings suggest a release against a recycled/wrong id before the crash. Notezig build test -Doptimize=ReleaseSafe(the FULL suite) was in neither local gate list — run it here and on every RPC change.Everything else was gate-green including e2e-l3-vatc 18/18. Fix the SEGV here, let the amd64 lanes prove it, then merge. Also coordinate with PR #8, which now conflicts with this tree in the e2e driver.
🤖 Generated with Claude Code