ci/spec22-gems: bisect the sassc closure through ffi on LoadError (incident 13 round 6) - #91
Merged
Merged
Conversation
…cident 13 round 6) Run 32188296332 attempt 2 (round-5 fix live, traces on) proves the closure walk COMPLETE: libsass.so's 15 imports parse (whole-image PE), both vendored siblings (libgcc_s_seh-1.dll, libwinpthread-1.dll) materialize beside the importer, every other import is KERNEL32 / ADVAPI32 / api-ms-win-crt-* host surface — and the ffi load still fails the OS bind with error 126. The walk, the placement, the ffi flags (0x8 ALTERED on every route), and the shim's errno discipline all check out; the failing link is only measurable on the windows loader itself. On the sassc require's LoadError, bisect the closure from inside through the same ffi path: two host-surface controls by bare name (ADVAPI32.dll; an api-ms-win-crt contract — both proven by the runtime's own boot), then each vendored sibling individually, then libsass.so again. The verdict matrix discriminates every remaining hypothesis: control failure = the host surface is broken in the scrubbed env; sibling failure = the extracted file is bad on disk (truncation, lock, quarantine); siblings ok + libsass retry ok = a transient race on the first load, not the closure; siblings ok + libsass retry 126 = an import the walk cannot see (delay-load excluded by design — would not 126 the base load — so this outcome reopens the parser). Never gates: the original LoadError re-raises after the verdicts. POSIX legs never fire it (green there).
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
2 participants
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.
Incident 13 round 6 — name the 126's failing link from inside the process
Run 32188296332 attempt 2 (round-5 fix live, traces on) proves the closure walk
complete: libsass.so's 15 imports parse (whole-image PE), both vendored
siblings (
libgcc_s_seh-1.dll,libwinpthread-1.dll) materialize beside theimporter, every other import is KERNEL32 / ADVAPI32 / api-ms-win-crt-* host
surface — and the ffi load still fails the OS bind with error 126.
Verified inert links (evidence in the r10 proof logs + source re-reads):
[tfs]traces show parse verdicts, per-dep resolve verdicts,materializations — all correct;
tail (
context.rs: extract_for_exec→root.join(host_tail(path)));DynamicLibrary.c:222—PathIsRelativeAeither way lands 0x8(
LOAD_WITH_ALTERED_SEARCH_PATH), the shim honors/forces it;touch the OS (the r10 error-5 first miss is the jail's EACCES on a
covered-but-not-held probe — correct behavior);
What remains is only measurable on the windows loader. This probe addition
bisects the closure from inside the jailed process through the same ffi
path on the require's LoadError:
ADVAPI32.dll(bare name) — control: a stock OS module;api-ms-win-crt-runtime-l1-1-0.dll(bare name) — control: an api-setcontract;
libwinpthread-1.dll(vendored, no in-image deps) — the base case;libgcc_s_seh-1.dll(vendored, depends on 3);libsass.so— the retry.Verdict matrix: control fail → host surface broken in the scrubbed env ·
sibling fail → extracted file bad on disk (truncation/lock/quarantine) ·
siblings ok + retry ok → transient race, not the closure · siblings ok +
retry 126 → an import the walk cannot see (reopens the parser).
Never gates: the original LoadError re-raises after the verdicts. POSIX legs
never fire it (green there). Both sassc legs ride it (same require).