Skip to content

Add ghc9123 variant and Windows TH crash stress harness#7836

Draft
zeme-wana wants to merge 1 commit into
masterfrom
claude/nervous-chatterjee-dea77b
Draft

Add ghc9123 variant and Windows TH crash stress harness#7836
zeme-wana wants to merge 1 commit into
masterfrom
claude/nervous-chatterjee-dea77b

Conversation

@zeme-wana

Copy link
Copy Markdown
Collaborator

What

The Windows (mingwW64) cross build of the plutus-core library intermittently fails with a GHC runtime crash while the Wine-hosted external interpreter (iserv) runs the cost-model Template Haskell splices ($$(readJSONFromFile ...) in PlutusCore.Evaluation.Machine.ExBudgetingDefaults):

iserv-proxy-interpreter.exe: internal error: scavenge_stack: weird activation record found on stack: 27
ghc-iserv terminated (1)

Example CI failure: https://ci.iog.io/build/13125016/nixlog/1

This PR adds a stress harness to measure how often the crash occurs per GHC toolchain:

  • scripts/windows-th-crash-stress.sh — cycles cold rebuilds (nix build --rebuild, so the binary cache is never reused) of projectCross.mingwW64.hsPkgs.plutus-core.components.library across three arms — ghc96, ghc912, ghc9123 — round-robin, classifies each build (target crash / other iserv crash / other failure / success) and tallies results into a CSV + summary table. Crash logs are kept, success logs dropped. Run on Linux with the IOG binary cache.
  • nix/project.nix — a ghc9123 flake variant (compiler-nix-name = "ghc9123").
  • nix/shell.nix / nix/outputs.nix — a ghc9123 dev shell (the lightweight quick-shell, since HLS/fourmolu/etc. have no GHC 9.12.3 releases yet).

Why ghc9123 needs special handling

GHC 9.12.3 ships RTS fix #25750 (underflow frame lookups in the bytecode interpreter) — the only plausibly-relevant change for this crash. But the project's pinned haskell.nix (ac987ef) does not ship GHC 9.12.3, and bumping the pin wholesale breaks the macOS dev shell (no GHC-9.12.3-compatible HLS/ghc-lib-parser releases). So:

  • the stress script selects a newer haskell.nix only at build time via --override-input haskell-nix github:input-output-hk/haskell.nix/d93d6edflake.lock is never touched;
  • the ghc9123 flake variant is inert under the pin (nothing in CI or the default shells evaluates it);
  • the ghc9123 devShell is gated on pkgs.haskell-nix.compiler ? ghc9123, so nix flake check/show keep working without the override. Enter it with nix develop .#ghc9123 --override-input haskell-nix <rev>.

Notes for reviewers

  • The haskell.nix override also advances iserv-proxy/nixpkgs (both crash-relevant), so a clean ghc9123 column vs a crashing ghc96 column is suggestive, not proof the GHC version is the cause. The script supports adding a ghc96-bumped arm (same GHC, bumped toolchain) to isolate that variable.
  • The first ghc9123 iteration cross-compiles the GHC 9.12.3 toolchain (not in IOG's cache) and is slow; later iterations rebuild only the plutus-core library. The ghc912 mingwW64 closure is also not built by CI, so its first iteration compiles all dependencies.
  • No changelog fragment: tooling/CI-investigation only, no library changes.

Pre-submit checklist:

  • Branch
    • Tests are provided (if possible) — n/a, investigation tooling
    • Commit sequence broadly makes sense
    • Key commits have useful messages
    • Changelog fragments have been written (if appropriate) — n/a
    • Relevant tickets are mentioned in commit messages
    • Formatting, PNG optimization, etc. are updated
  • PR
    • Targeting master unless this is a cherry-pick backport
    • Self-reviewed the diff
    • Useful pull request description
    • Reviewer requested

The Windows (mingwW64) cross build of plutus-core intermittently dies
with 'scavenge_stack: weird activation record found on stack' while the
Wine-hosted iserv runs the cost-model TH splices (e.g.
https://ci.iog.io/build/13125016/nixlog/1).

Add scripts/windows-th-crash-stress.sh, which cycles cold rebuilds
(nix build --rebuild) of the mingwW64 plutus-core library across ghc96,
ghc912 and ghc9123 arms and tallies how often each hits the crash.

GHC 9.12.3 (RTS fix #25750) is not in the pinned haskell.nix, so the
ghc9123 flake variant and dev shell are inert under the pin: the script
selects a newer haskell.nix via --override-input at build time, and the
ghc9123 devShell is gated on the compiler being present so flake
evaluation keeps working without the override.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant