Windows build cleanup can select processes outside the requested work folder #2142

Closed

opened 2026-11-11 04:47:25 +00:00 by Arkex-ai · 1 comment

Arkex-ai commented

2026-11-11 04:47:25 +00:00

(Migrated from github.com)

Problem

At main revision 07b03596, nx2/make_game.py::stop_stray_compilers can select processes outside the requested work folder. Starting or retrying one Windows build could therefore stop another build or compiler. This is a source-selector reproduction, not a report of a real process being terminated.

Two paths admit unrelated processes:

An orphan Python command containing build.py or lift.py and --standalone is selected without checking its work directory.
Compiler matching uses a substring of the work path, so C:\authored-cleanup\work-other\obj.o matches cleanup for C:\authored-cleanup\work.

Reproduction

I extracted the actual function with Python AST and called it with authored CIM rows. subprocess.run was replaced by a stub: it returns that table for the PowerShell query and records requested taskkill PIDs without executing them. Time delays were also mocked.

Synthetic process	Command	Selected by production helper
Orphan Python, unrelated folder	`python C:\another-repo\nx2\lift.py --standalone --work C:\another-repo\work --write`	Yes
Compiler, sibling-prefix folder	`clang -c input.c -o C:\authored-cleanup\work-other\obj.o`	Yes
Orphan lift, intended folder	`python C:\this-repo\nx2\lift.py --standalone --work C:\authored-cleanup\work --write`	Yes

All three synthetic PIDs were selected. No real PowerShell command, taskkill, game or build was run. The helper's source is unchanged between the tested parent and the main revision above. Linux currently returns before this cleanup.

Expected behavior and scope

Only a process positively associated with the requested work folder should be eligible for cleanup. Preserve current-process/ancestor exclusions and cleanup of proven stale target work. An absent parent does not establish which folder an orphan uses; an unproven folder should not authorize termination.

The fix needs tests for explicit/default work paths, spaces/Unicode, sibling prefixes, similarly named scripts, missing ownership metadata and live/dead parents. The process table and termination calls should stay synthetic, or integration must be restricted to explicitly created test children. This does not require game files.

Related background: #501 and #530 explain why stale-build cleanup exists. This issue concerns its folder isolation, not removing cleanup. Initial open-PR searches for stop_stray_compilers and orphan found no matching work; no production implementation has started.

## Problem At main revision `07b03596`, `nx2/make_game.py::stop_stray_compilers` can select processes outside the requested work folder. Starting or retrying one Windows build could therefore stop another build or compiler. This is a source-selector reproduction, not a report of a real process being terminated. Two paths admit unrelated processes: - An orphan Python command containing `build.py` or `lift.py` and `--standalone` is selected without checking its work directory. - Compiler matching uses a substring of the work path, so `C:\authored-cleanup\work-other\obj.o` matches cleanup for `C:\authored-cleanup\work`. ## Reproduction I extracted the actual function with Python AST and called it with authored CIM rows. `subprocess.run` was replaced by a stub: it returns that table for the PowerShell query and records requested taskkill PIDs without executing them. Time delays were also mocked. | Synthetic process | Command | Selected by production helper | |---|---|---| | Orphan Python, unrelated folder | `python C:\another-repo\nx2\lift.py --standalone --work C:\another-repo\work --write` | Yes | | Compiler, sibling-prefix folder | `clang -c input.c -o C:\authored-cleanup\work-other\obj.o` | Yes | | Orphan lift, intended folder | `python C:\this-repo\nx2\lift.py --standalone --work C:\authored-cleanup\work --write` | Yes | All three synthetic PIDs were selected. No real PowerShell command, taskkill, game or build was run. The helper's source is unchanged between the tested parent and the main revision above. Linux currently returns before this cleanup. ## Expected behavior and scope Only a process positively associated with the requested work folder should be eligible for cleanup. Preserve current-process/ancestor exclusions and cleanup of proven stale target work. An absent parent does not establish which folder an orphan uses; an unproven folder should not authorize termination. The fix needs tests for explicit/default work paths, spaces/Unicode, sibling prefixes, similarly named scripts, missing ownership metadata and live/dead parents. The process table and termination calls should stay synthetic, or integration must be restricted to explicitly created test children. This does not require game files. Related background: #501 and #530 explain why stale-build cleanup exists. This issue concerns its folder isolation, not removing cleanup. Initial open-PR searches for `stop_stray_compilers` and `orphan` found no matching work; no production implementation has started.

Arkex-ai commented

2026-11-11 04:58:33 +00:00

(Migrated from github.com)

S0 × Windows reach 0.57 upper bound × confidence 1.0 for the reproduced selector failures, not a real termination. The evidence uses synthetic CIM rows and a fake taskkill; no real process was stopped.

Claimed in #dev-work before production edits. The initial reproduction was on 07b03596; the same failure also reproduces on ebbba2ea. The candidate is now under validation: 10 focused cases pass, including positive cleanup, sibling prefixes, unknown orphans, quoted paths, ancestor protection and a known build child. Full Windows/Linux checks are in progress. Please flag any overlapping work.

I'm taking #2142 (Arkex-ai): restrict stale-build cleanup to processes with positive ownership of the selected work folder, preserving useful cleanup and current-process/ancestor protection. Scope includes argument/path boundaries and unknown orphan ownership; no broad process-management rewrite. S0 × Windows reach 0.57 upper bound × confidence 1.0 for the reproduced selector failures, not a real termination. The evidence uses synthetic CIM rows and a fake taskkill; no real process was stopped. [Claimed in #dev-work before production edits](https://discord.com/channels/1568810484818378804/1569019786766188665/1570037297234051113). The initial reproduction was on `07b03596`; the same failure also reproduces on `ebbba2ea`. The candidate is now under validation: 10 focused cases pass, including positive cleanup, sibling prefixes, unknown orphans, quoted paths, ancestor protection and a known build child. Full Windows/Linux checks are in progress. Please flag any overlapping work.