fix(build): stop sampling memory for exited compiler roots #1562

Merged

Arkex-ai merged 1 commit from fix/compiler-memory-liveness into main

2026-11-10 08:49:37 +00:00

Arkex-ai commented

2026-11-10 08:16:16 +00:00

(Migrated from github.com)

The build memory gate samples a compiler's process tree by PID even after its retained Popen has reported completion. A stale counter or a PID found in a later snapshot can therefore contribute memory for a compiler that has ended; the existing child-memory regression already expects zero in that state.

Check Popen.poll() before querying the platform counter. Known-ended roots, including exitcode0, return zero without a PID lookup. Live compilers still include their descendants, and unavailable counters keep the existing zero fallback. Peak estimates, reserves, worker floors and lease release are unchanged. This does not make process-tree sampling atomic or solve every exit/PID-ancestry race.

Validation at 2154b47 on main ff69134:

New regression keeps an actual completed Popen alive while the backend offers a stale512MiB value. Original main fails; the fix returns zero without querying the backend. The same fixture verifies live-tree sampling and unavailable counters.
Removing the guard, treating exitcode0 as still live, or inverting the liveness check all fail by assertions.
Windows and Linux pass the liveness fixture, the existing real300MiB child regression, memory-gate tests and four lease tests. No compiler or game dump is needed for these lifecycle/scheduling checks.
Full Windows suite228 passed/3 failed/20 skipped versus exact main227/3/20; identical NUP link-privilege, local C++ header and Windows SDK limitations. No new failures or relaxed assertions.

A Windows source CI initially exposed the ended-process assertion while validating an unrelated capture PR. A later local run passed, so the deterministic stale-counter case is kept rather than relying on retrying that integration test. The exact OS counter behind that original run is not claimed as instrumented. See docs/compiler-memory-accounting.md. No game/runtime files or unrelated scheduler changes are included; three exact-head fork workflows follow.

Current-head validation

Current head a014f6c, based on main be541fa. Earlier local/runtime results describe their recorded source hashes.

The standalone contribution patch is unchanged after the audited main refresh; exact-head build/source checks are refreshed below. Earlier runtime evidence remains tied to its recorded hash.

Fork runs are separate from upstream Actions approval; no maintainer approval gate is bypassed.

The build memory gate samples a compiler's process tree by PID even after its retained `Popen` has reported completion. A stale counter or a PID found in a later snapshot can therefore contribute memory for a compiler that has ended; the existing child-memory regression already expects zero in that state. Check `Popen.poll()` before querying the platform counter. Known-ended roots, including exitcode0, return zero without a PID lookup. Live compilers still include their descendants, and unavailable counters keep the existing zero fallback. Peak estimates, reserves, worker floors and lease release are unchanged. This does not make process-tree sampling atomic or solve every exit/PID-ancestry race. Validation at `2154b47` on main `ff69134`: - New regression keeps an actual completed Popen alive while the backend offers a stale512MiB value. Original main fails; the fix returns zero without querying the backend. The same fixture verifies live-tree sampling and unavailable counters. - Removing the guard, treating exitcode0 as still live, or inverting the liveness check all fail by assertions. - Windows and Linux pass the liveness fixture, the existing real300MiB child regression, memory-gate tests and four lease tests. No compiler or game dump is needed for these lifecycle/scheduling checks. - Full Windows suite228 passed/3 failed/20 skipped versus exact main227/3/20; identical NUP link-privilege, local C++ header and Windows SDK limitations. No new failures or relaxed assertions. A Windows source CI initially exposed the ended-process assertion while validating an unrelated capture PR. A later local run passed, so the deterministic stale-counter case is kept rather than relying on retrying that integration test. The exact OS counter behind that original run is not claimed as instrumented. See `docs/compiler-memory-accounting.md`. No game/runtime files or unrelated scheduler changes are included; three exact-head fork workflows follow.  ### Current-head validation Current head `a014f6c`, based on main `be541fa`. Earlier local/runtime results describe their recorded source hashes. The standalone contribution patch is unchanged after the audited main refresh; exact-head build/source checks are refreshed below. Earlier runtime evidence remains tied to its recorded hash. - [Linux AppImage](https://github.com/Arkex-ai/Hookshot/actions/runs/42783338691): in_progress. - [Windows builder](https://github.com/Arkex-ai/Hookshot/actions/runs/42783333109): queued. - [Game-free source regressions](https://github.com/Arkex-ai/Hookshot/actions/runs/42783329109): queued. Fork runs are separate from upstream Actions approval; no maintainer approval gate is bypassed.