GeezerVison

Something is very wrong with Windows on this.

I've been investigating this. Here's a summary:

What's happening

The Windows test binary is hitting Go's default 10-minute per-package timeout. All failures show (unknown) status — no test actually fails an assertion, they're just killed mid-execution. The goroutine dumps in the logs confirm this: goroutines are stuck in normal operations (selectgo, IO wait, sync.WaitGroup.Wait) when the timeout fires.

Run 1: DONE 2010 tests, 72 skipped, 781 failures in 56.673s (cold cache)
Run 2: DONE 2096 tests, 81 skipped, 59 failures in 94.478s (warm cache, got further)

Root cause

Go 1.26 introduces the Green Tea GC as the default garbage collector. There are known Windows-specific issues:

• golang/go#77567: High memory usage on Windows with Go 1.26 (Green Tea GC related)
• golang/go#77407: os.RemoveAll regression on Windows (backported to Go 1.26.1)

The test suite runs heavyweight integration tests (HTTP servers, wireguard tunnels, embedded postgres) in parallel. The new GC appears to cause enough overhead on Windows to push the tests past their timeout.

Options

1. GOEXPERIMENT=nogreenteagc — disable Green Tea GC at build time for the Windows test job to confirm this is the cause
2. Increase Windows test timeout — add -timeout 20m to GOTEST_FLAGS (currently using Go's 10m default)
3. Wait for Go 1.26.1 — which will include fixes for the Windows-specific issues
4. Reduce Windows test parallelism — currently 8 packages × 16 tests = 128 concurrent tests

Windows CI Failure Investigation

The test-go-pg (windows-2022) job is failing with 621 out of 2386 tests marked as failures. This is caused by a known Go runtime bug affecting Go 1.26.0 and 1.26.1 on Windows — not related to any code changes in this PR.

Root Cause

The crash signature is:

fatal error: unexpected signal during runtime execution
panic during panic
[signal 0xc0000005 code=0x0 addr=0xe8 pc=0x7ff70ebdab05]

This is an ACCESS_VIOLATION in runtime.(*unwinder).next during runtime.scanstack → runtime.markroot (GC stack scanning). The underlying issue is in internal/poll on Windows: WSARecvFrom writes to the rsan (address length) parameter after overlapped I/O completes. When rsan is a local stack variable inside a closure, and the goroutine's stack is moved/shrunk between the syscall initiation and completion, Windows writes to the old (now-invalid) stack address, corrupting return addresses.

Notably, this is not caused by the Green Tea GC — GOEXPERIMENT=nogreenteagc still reproduces the crash.

Upstream Tracking

• Original report: runtime: Windows crash with Go 1.26.0, 1.26.1 golang/go#77975 (closed, fixed)
• 1.26 backport: runtime: Windows crash with Go 1.26.0, 1.26.1 [1.26 backport] golang/go#78041 (closed, cherry-picked)
• Fix CL: https://go-review.googlesource.com/c/go/+/753040 — moves rsan from the goroutine stack to the heap
• Fix target: Go 1.26.2 (not yet released)

Ubuntu CI Failure

The test-go-pg (ubuntu-latest) failure is unrelated — only 2 test failures out of 17,351 (TestRun/RPTY timeout), which appears to be a flaky test.

Recommendation

The Windows failure can be ignored until Go 1.26.2 is released with the fix. This PR should be safe to merge once rebased onto the latest main and the non-Windows checks pass.