runtime,cmd/compile: `exit status 0xc0000374` (`STATUS_HEAP_CORRUPTION`) on windows-amd64-longtest

[bcmills]

#!watchflakes
post <- builder ~ `windows` && `0xc0000374`

XXXBANNERXXX:Test execution environment.
# GOARCH: amd64
# CPU: Intel(R) Xeon(R) CPU @ 2.20GHz
# GOOS: windows
# OS Version: 10.0.14393
go tool compile: exit status 0xc0000374

go tool dist: FAILED: go list -f={{if .Stale}}	STALE {{.ImportPath}}: {{.StaleReason}}{{end}} std: exit status 1

According to https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55, this exit code means:

0xC0000374
STATUS_HEAP_CORRUPTION
A heap has been corrupted.

---

greplogs --dashboard -md -l -e \(\?ms\)\\Awindows-.\*0xc0000374

2022-04-27T14:23:28-f0c0e0f/windows-amd64-longtest

Since this has only been seen once, leaving on the backlog to see whether this is a recurring pattern or a one-off fluke.
(CC @golang/runtime)

[bcmills]

Re-running the scan due to the possibility of failures masked by #52591:

greplogs --dashboard -md -l -e \(\?ms\)\\Awindows-.\*0xc0000374
2022-05-06T14:33:48-119da63/windows-amd64-longtest
2022-04-27T14:23:28-f0c0e0f/windows-amd64-longtest

[bcmills]

That's two matching failures within the Go 1.19 cycle (and even within the past couple weeks!) on windows/amd64, which is a first-class port, and none before that. Looks like a release-blocking regression to me.

(CC @golang/windows)

[bcmills]

One more:
greplogs --dashboard -md -l -e \(\?ms\)\\Awindows-.\*0xc0000374 --since=2022-05-07
2022-05-10T15:43:40-8fdd277/windows-amd64-longtest

[prattmic]

Three days of continuous testing on 25 windows gomotes has gotten me zero of these failures, so I suspect I am missing some required component of the failure.

[bcmills]

None on the dashboard for the past week or so, although that's somewhat to be expected with the CL rate decreasing from the freeze.

greplogs --dashboard -md -l -e \(\?ms\)\\Awindows-.\*0xc0000374 --since=2022-05-11

(0 matching logs)

---

Note that this has only been observed in the -longtest configuration, which is surprising because these failures all occurred during compilation! 😅

Maybe it has something to do with the shape of the machine? IIRC the -longtest builders have more RAM and perhaps also more CPUs. 🤔

(Or maybe it's some sort of crosstalk between tests and builds somehow? But that seems even more weird.)