This crash seems sporadic, so it's not clear to me whether this is a 1.18 regression. We should probably at least figure out whether there is a memory-corruption problem on this platform before the 1.18 release.

/cc @ zx2c4 @bufflig Would you be able to take a look at this issue?

I can see if I can reproduce it, but it looks like an issue that just happens to show up on windows and is actually not really windows specific. It's quite probable that someone from the runtime team proper has a higher chance of finding this problem.

The zombie object is at 0x40006adc30 whereas this stack is actively using it

goroutine 268 [semacquire]:
fmt.glob..func1()
	C:/workdir/go/src/fmt/print.go:132 +0x28
sync.(*Pool).Get(0x7ff7d0d79c60)
	C:/workdir/go/src/sync/pool.go:148 +0xc0
fmt.newPrinter()
	C:/workdir/go/src/fmt/print.go:137 +0x28
fmt.Sprint({0x40006adc30, 0x1, 0x1})
	C:/workdir/go/src/fmt/print.go:248 +0x2c
text/template.evalArgs({0x40006adc30?, 0x1?, 0x1?})
	C:/workdir/go/src/text/template/funcs.go:750 +0xa0
text/template.HTMLEscaper({0x40006adc30?, 0x7ff7d044ebac?, 0x1?})
	C:/workdir/go/src/text/template/funcs.go:631 +0x24
reflect.Value.call({0x7ff7d0888e80?, 0x7ff7d09d8b68?, 0x7ff7d0aa7ef8?}, {0x7ff7d091cbc1, 0x4}, {0x400083f7d0, 0x1, 0x6?})
	C:/workdir/go/src/reflect/value.go:543 +0x5c0
reflect.Value.Call({0x7ff7d0888e80?, 0x7ff7d09d8b68?, 0x400015e040?}, {0x400083f7d0, 0x1, 0x1})
	C:/workdir/go/src/reflect/value.go:339 +0x98
text/template.safeCall({0x7ff7d0888e80?, 0x7ff7d09d8b68?, 0x400015e040?}, {0x400083f7d0?, 0x7ff7d0aa7ef8?, 0x7ff7d0895d80?})
	C:/workdir/go/src/text/template/funcs.go:368 +0x68
text/template.(*state).evalCall(0x4000b4b3d8, {0x7ff7d0897f40?, 0x400015e040?, 0x2c78283267724164?}, {0x7ff7d0888e80?, 0x7ff7d09d8b68?, 0xa7d090a65757274?}, 0x1, {0x7ff7d0aa6c58?, 0x4000132ab0}, ...)

I wonder if we fail to keep something alive, possibly especially related to reflect.Value.call.

Change https://golang.org/cl/363358 mentions this issue: reflect: keep pointer in aggregate-typed args live in Call

The CL above is likely to fix the crash in 2021-10-29T02:16:47-d6a9af8-2c7cdec/windows-arm64-10.

2021-10-11T21:58:33-18fa840-d973bb1/windows-arm64-10 doesn't contain that pattern so it may or may not be the same error.It could be a memory corruption like the other one earlier then causes the error, or it could be something else.

Change https://golang.org/cl/369158 mentions this issue: [release-branch.go1.17] reflect: keep pointer in aggregate-typed args live in Call