cmd/compile: "internal compiler error: curfn mismatch" on darwin-amd64-race builder

[bcmills]

#!watchflakes
post <- log ~ `internal compiler error: curfn mismatch`

2021-01-18T17:21:53-5a8fbb0/darwin-amd64-race

See previously #37407, #37406, but note that those were believed to have been fixed by upgrading the builders.
(CC @randall77 @josharian @golang/release)

[mdempsky]

That seems like memory corruption. Either runtime bugs or faulty memory or something. That sort of failure shouldn't be random.

Another failure on the same machine, which also looks like a pointer is nil when it shouldn't be: https://build.golang.org/log/9a0af1fedad51a17898be428620c03c863e258a0

And another similar failure on the non-race version of the machine (not sure if the same physical hardware or not): https://build.golang.org/log/5e5d23f0d609ad291d7be138ef1ff147a6c613b1

[mdempsky]

That last one definitely looks like some sort of memory corruption. The error message is:

vet: [...]/go/src/reflect/type.go:2611:57: tt.Elem().Field(0).hodsTypeOf undefined (type Value has no field or method hodsTypeOf)

but that corresponding line of source is:

                typ = (*structType)(unsafe.Pointer(tt.Elem().Field(0).UnsafeAddr()))

So the string that should be "UnsafeAddr" is actually "hodsTypeOf"? Notably, the same length, but wrong bytes. It looks like maybe the string data for "methods" and "TypeOf" are consecutive in memory, and the pointer for "UnsafeAddr" is off.

[bcmills]

Agreed, it looks like memory corruption. My question is, is this memory corruption due to a hardware issue (e.g. overheading RAM), due to a kernel or platform bug, or due to a bug somewhere in the Go toolchain or runtime?

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)