← board

Track guessed as P from the FAILING STEP — line 2 of 2, ok=0; \ for t in native i386 arm32 aarch64 riscv32 xtensa wasm32; do \ case $t in \ native) bin=/tmp/fxpal26; run="";; \, which names test/test_cross_futex_through_the_pal.pas. Not from the job's name or its src: those describe what the job is ABOUT, and this job's recipe spans 3 source file(s). The ranker reads frontmatter, so this line — not the body — decides who works it; correct it if the guess is wrong.

origin/master has advanced 1 commit(s) since this sha. Re-verify at current HEAD before acting — the callback is tagged to the sha that was tested, which may no longer be the state of the tree.

first-ever red: test-core#src:test/test_cross_futex_through_the_pal.pas at 0f13a3b760a3 in step 2/2, ok=0; \ for t in native i386 arm32 aarch64 riscv32 xtensa wasm32; do \ case $t in \ native) bin=/tmp/fxpal26; run="";; … (auto-filed by twatch)

Repro

tools/testmgr.py --tier native --job 'test-core#src:test/test_cross_futex_through_the_pal.pas' at 0f13a3b760a337b82961e10c25986938125b76fb

Range

The named sha 0f13a3b760a3 CANNOT be the cause — it touches no buildable file (docs / tickets / tstate only). It is the sha that was TESTED, i.e. the upper bound of an untested range; the cause is somewhere below it.

bad 0f13a3b760a3, and this is the job's first-ever run — there is no earlier passing sha, so no interval contains the cause and every commit a range could name is equally innocent. No idle bisect will happen; a red here is a finding about the job, not a regression from the commits around it.

Log tail

  fxpal: PASS native (2^32+1 s did not return -- tv_sec is 64-bit)
  fxpal: PASS i386 (2^32+1 s truncated to 1 -- correct, its futex tv_sec IS 32-bit)
  fxpal: PASS arm32 (2^32+1 s truncated to 1 -- correct, its futex tv_sec IS 32-bit)
  fxpal: PASS aarch64 (2^32+1 s did not return -- tv_sec is 64-bit)
  fxpal: PASS riscv32 (2^32+1 s did not return -- tv_sec is 64-bit)
  fxpal: PASS xtensa (2^32+1 s truncated to 1 -- correct, its futex tv_sec IS 32-bit)
wasmtime not found (looked on PATH and in ~/.local/bin)
expect_same: MISMATCH [fxpal/wasm32-basic]
--- expected
+++ actual
@@ -1 +1 @@
-wake=-38 wait=-38 waitto=-38
+

Stub ticket: signal only. Track T agent (face 2) enriches or a dev track takes it from the repro line.

Not a regression — the host had no wasmtime (frankA, 2026-09-04)

Six auto-filed tickets, six different test names, six different commits, ONE missing binary. This is one of them. The whole set: test-cross-frozen-ptr-narrow, -frozen-ptr-in-field, -typeinfo-dataref, -dynarray-slot-store, -os-entropy-through-the-pal, -futex-through-the-pal.

The log tail of every one of them carries the line wasmtime not found (looked on PATH and in ~/.local/bin) immediately above the mismatch. tools/run_target.sh printed that on stderr and exited 2 — but every Makefile assertion calls it inside "$(tools/run_target.sh wasm32 ...)", and a command substitution captures stdout and discards the exit code. The comparison therefore ran with the empty string, and the diff reads exactly like wasm32 emitting nothing:

-fld16  T [AB] 2 [AB] [xAB] A
 ...
+

Re-measured on a host that HAS wasmtime, at the same tree, all six pass:

ENTROPY OK / DYNSLOTSTORE OK / FROZENPTRFIELD OK / FROZENPTRNARROW OK
enums OK, header Integer, header TPoint / fxpal all three modes

What was fixed, and what was not

tools/run_target.sh now reports an absent runner on stdout as well, as RUNNER-ABSENT: <tool> not found, so target '<arch>' was NOT RUN, for the qemu arms too. It still exits nonzero and the row still goes red — an unrun test is not a passing test — but the row now names the HOST instead of accusing the target, and the next auto-filed ticket will carry that sentence in its own log tail.

What was NOT fixed is the actual gap: host seven has no wasmtime, so every wasm32 row there is unverified. That is a machine, not a tree, and it is not mine to change.

The reading that nearly cost more than it did

Four of these were read as four separate defects in four freshly added tests, because each names its own test and its own commit and nothing in a ticket says "the other five say this too". The distinguishing observation was free and was in the ticket already: the fix a50671107 landed 15:41Z and the test went red at 15:56Z, so the fix was in the tree when the test failed — which no compiler-state story explains. Read the log tail above the diff before reading the diff.