Skip to content

Chapel Metalayer

Jump to bottom
hyperpolymath edited this page Jun 2, 2026 · 5 revisions

Chapel metalayer

panic-attack's Rust binary stands alone (USB-portable, single-machine). The Chapel metalayer in chapel/ is a detachable multi-machine harness that shells out to the Rust binary across many repos with fNIRS-inspired temporal aggregation. Two things to keep straight:

Concern Lives in
Static analysis, taint tracking, 25 weak-point categories, CVE triage Rust binary (src/)
Orchestrating that binary across hundreds of repos with cross-locale aggregation, temporal snapshots, VeriSimDB hexad persistence Chapel metalayer (chapel/)

The metalayer is optional. You only need it if you're running estate-scale sweeps (mass-panic).

CI gate topology

The chapel-ci workflow runs seven strict jobs plus an always-on aggregator (chapel-ci-gate). All seven are path-filtered to chapel-relevant changes; the aggregator surfaces success/failure to the Base ruleset without ever leaving "expected but not reported" deadlocks.

# Job What it proves
1 chapel-parse-check chpl --parse-only clean across every module
2 chapel-build chpl build of mass-panic + smoke (no toolbox)
3 chapel-smoke chapel/smoke/two_repo_smoke — data flow through the metalayer
4 chapel-e2e mass-panic -nl 1 on a synthetic 2-repo manifest (single locale)
5 chapel-cli-contract panic-attack describe-contract matches the expected fixture
6 chapel-rust-diff rayon assemblyline vs Chapel single-locale parity
7 chapel-multilocale mass-panic --numLocales=2 against gasnet+smp Chapel (Wave 2, #87)

The aggregator runs on every push/PR; the seven gates run only when chapel/** or the Rust contract files change. On unrelated changes the aggregator reports SUCCESS immediately and unblocks the ruleset.

Wave 2 toolchain (chapel-multilocale)

The Wave 1 install path was the chapel-2.8.0-1.ubuntu22.amd64.deb from chapel-lang/releases. That .deb is single-locale only (CHPL_COMM=none), so it can't exercise the coforall on Locales code paths that make the metalayer interesting at estate scale.

Wave 2 builds Chapel from source with multilocale comms enabled:

CHPL_COMM:           gasnet      # multilocale communication layer
CHPL_COMM_SUBSTRATE: smp         # shared-memory substrate (no NIC needed)
CHPL_LAUNCHER:       smp         # spawn locales as local processes
CHPL_TARGET_COMPILER: gnu

smp substrate means we get cross-locale aggregation semantics on a single host via oversubscribed processes — perfect for CI, where we just need to prove mass-panic --numLocales=2 actually exercises the multi-locale code path, not just spawns 2 processes that each scan everything.

Cache strategy. $CHPL_HOME = /opt/chapel-multilocale (~2-3 GB after build) is restored via actions/cache@v4 keyed on ${runner.os}-chapel-multilocale-${CHAPEL_VERSION}-gasnet-smp-${CHAPEL_MULTILOCALE_CACHE_GEN}. Cold build ~30-40 min on a 2-core runner; warm restore ~30s. The 7-day idle eviction policy applies, so a repo that doesn't touch chapel/ for 8+ days pays the cold-build cost on the next change.

Manual cache invalidation. Bump the CHAPEL_MULTILOCALE_CACHE_GEN env var (v1 → v2 …) in chapel-ci.yml whenever you change build flags or want to force a fresh build. The cache key includes this counter, so no gh cache delete round-trip is needed.

Verification step. The gate runs mass-panic --numLocales=2 --repoDirectory=<two-repo synthetic corpus> --quiet --outputDir=<tmp> and then greps the emitted system-image-*.json for both repo-alpha and repo-beta. This proves the binary spawned multiple locales AND aggregated their findings back into a single SystemImage — passing this gate means cross-locale aggregation works, not just multi-process spawn.

What Wave 2 does NOT close

  • Wave 3: cross-node gasnet/ofi over a real NIC. Default GH runners are single-host; meaningful multi-node testing needs cluster runners. Tracked in ROADMAP.adoc v3.0.0.
  • The "~5-15% slower" benchmark claim at chapel/README.md lines 72/131/163/175/183 for queue vs static scheduler. Needs a ~50-repo workload on a beefier runner to produce meaningful numbers.

Known sharp edges

  • MANPATH unbound under set -u. util/setchplenv.bash references ${MANPATH} unconditionally. On a clean runner with set -u active in the calling step, this trips MANPATH: unbound variable. The Wave 2 workflow exports MANPATH=${MANPATH:-} before sourcing — replicate this pattern if you add new chapel-from-source steps.

  • CHPL_LLVM required for source build. Chapel's make step verifies clang/Basic/Version.h before building and aborts with a chplenv-verify failure if LLVM dev headers aren't installed. Set CHPL_LLVM=none to disable the LLVM backend entirely (we only need the gnu C backend for multilocale comms). Alternatives are bundled (slow — builds LLVM from source) or system (needs apt-get install llvm-*-dev clang-*-dev).

  • chpl --about is gone in 2.8.0. And "$CHPL_HOME/util/printchplenv" --simple does NOT emit a clean CHPL_COMM=gasnet line on a fresh build (output format isn't what the docs suggest, or there's a chplenv-cache priming step we missed). Use a format-independent runtime-layout check instead: Chapel names $CHPL_HOME/lib/<plat>/<compiler>/<arch>/loc-flat/comm-gasnet/smp/<tasks>/launch-smp/ per (comm, launcher, ...) variant. Existence of comm-gasnet/smp/.../launch-smp proves the build picked up CHPL_COMM+CHPL_LAUNCHER.

  • Source tarball not yet SHA-pinned. Tracker comment lives in the workflow header. Wave 2 hardening will pin both the .deb (Wave 1) and the source tarball (Wave 2).

  • Runner ABI mismatch (added 2026-06-02 via echidna#183). Chapel 2.8.0's debian package is chapel-2.8.0-1.ubuntu22.amd64.deb and links its compiler driver against libclang-cpp.so.14 (LLVM-14 / Ubuntu 22.04). On Ubuntu 24.04 (= runs-on: ubuntu-latest) apt resolves the unmet dependency with libclang-cpp-18, leaving chpl unable to load:

    chpl: error while loading shared libraries: libclang-cpp.so.14:
      cannot open shared object file: No such file or directory
exit code 127

    Workaround. Pin every Chapel-using job to runs-on: ubuntu-22.04. Also prefer apt-get install -y /tmp/chapel.deb over dpkg -i /tmp/chapel.deb || apt-get install -f -y: the apt-get form resolves libclang-cpp14 / libllvm14 declaratively in one pass instead of relying on the post-failure fix path.

    Detection. Hypatia rule WF024 (added in hypatia#414) matches CHAPEL_DEB_URL envvar or chapel-X.Y.Z-N.ubuntu22.amd64.deb filename in workflow YAML and cross-references the runs-on: — flags ubuntu-latest / ubuntu-24.04 as ABI mismatch.

Files

  • .github/workflows/chapel-ci.yml — the 7-job + aggregator workflow
  • chapel/src/MassPanic.chpl — orchestrator entry point (mass-panic binary)
  • chapel/src/Protocol.chpl — fNIRS-inspired SystemImage protocol
  • chapel/src/Imaging.chpl — cross-locale image aggregation
  • chapel/src/Temporal.chpl — temporal snapshot diffing
  • chapel/README.md — operator docs (modes, options, schedulers)

Related

panic-attack

Detection

Integration

Scale

Verification

Development

Clone this wiki locally