runtime: 'unexpected fault address 0x0' in evacuate_fast32 on linux-mips64le-mengzhuo builder

[bcmills]

From the linux-mips64le-mengzhuo builder (https://build.golang.org/log/859e1e89ae0a2ecad12c9e2cf70691e26b3d7f05):

unexpected fault address 0x0
fatal error: fault
[signal SIGBUS: bus error code=0x80 addr=0x0 pc=0x226c4]

goroutine 23 [running]:
runtime.throw(0xad323a, 0x5)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/runtime/panic.go:774 +0x6c fp=0xc000de0980 sp=0xc000de0958 pc=0x471a4
runtime.sigpanic()
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/runtime/signal_unix.go:405 +0x5c8 fp=0xc000de09a8 sp=0xc000de0980 pc=0x62a78
runtime.evacuated(...)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/runtime/map.go:203
runtime.evacuate_fast32(0xa727c0, 0xc0006405a0, 0x3)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/runtime/map_fast32.go:367 +0x8c fp=0xc000de0a58 sp=0xc000de09b0 pc=0x226c4
runtime.growWork_fast32(0xa727c0, 0xc0006405a0, 0x7)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/runtime/map_fast32.go:356 +0x8c fp=0xc000de0a78 sp=0xc000de0a58 pc=0x225e4
runtime.mapassign_fast32(0xa727c0, 0xc0006405a0, 0xb, 0x126caa0)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/runtime/map_fast32.go:115 +0x370 fp=0xc000de0ab0 sp=0xc000de0a78 pc=0x22058
cmd/compile/internal/ssa.(*poset).newnode(...)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/ssa/poset.go:254
cmd/compile/internal/ssa.(*poset).SetEqual(0xc0008fc980, 0xc0007af4e0, 0xc0007af5c0, 0xc000c7e548)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/ssa/poset.go:1019 +0x474 fp=0xc000de0b40 sp=0xc000de0ab0 pc=0x2a3ccc
cmd/compile/internal/ssa.(*factsTable).update(0xc000bec480, 0xc0007e5c40, 0xc0007af4e0, 0xc0007af5c0, 0x1, 0x2)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/ssa/prove.go:238 +0x2798 fp=0xc000de0d90 sp=0xc000de0b40 pc=0x2a9118
cmd/compile/internal/ssa.addRestrictions(0xc0007e5c40, 0xc000bec480, 0x3, 0xc0007af4e0, 0xc0007af5c0, 0x2)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/ssa/prove.go:1049 +0x98 fp=0xc000de0dd0 sp=0xc000de0d90 pc=0x2ac788
cmd/compile/internal/ssa.addBranchRestrictions(0xc000bec480, 0xc0007e5c40, 0x1)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/ssa/prove.go:1030 +0x364 fp=0xc000de0e30 sp=0xc000de0dd0 pc=0x2ac564
cmd/compile/internal/ssa.prove(0xc000e90160)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/ssa/prove.go:888 +0x980 fp=0xc000de2088 sp=0xc000de0e30 pc=0x2aad68
cmd/compile/internal/ssa.Compile(0xc000e90160)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/ssa/compile.go:92 +0x948 fp=0xc000de5cf8 sp=0xc000de2088 pc=0x25f978
cmd/compile/internal/gc.buildssa(0xc0010e54a0, 0x2, 0x0)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/gc/ssa.go:289 +0x87c fp=0xc000de5ea8 sp=0xc000de5cf8 pc=0x93d6ac
cmd/compile/internal/gc.compileSSA(0xc0010e54a0, 0x2)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/gc/pgen.go:298 +0x48 fp=0xc000de5f98 sp=0xc000de5ea8 pc=0x902340
cmd/compile/internal/gc.compileFunctions.func2(0xc000b890e0, 0xc000f5ab50, 0x2)
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/gc/pgen.go:363 +0x54 fp=0xc000de5fc0 sp=0xc000de5f98 pc=0x9d7d74
runtime.goexit()
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/runtime/asm_mips64x.s:646 +0x4 fp=0xc000de5fc0 sp=0xc000de5fc0 pc=0x7ec94
created by cmd/compile/internal/gc.compileFunctions
	/tmp/workdir-host-linux-mipsle-mengzhuo/go/src/cmd/compile/internal/gc/pgen.go:361 +0x17c

CC @randall77 @aclements

[randall77]

This seems not possible.
evacuate_fast32 is only called when h.growing() is true, which is when h.oldbuckets != nil. But evacuate_fast32 passes h.oldbuckets to evacuated, and evacuated then nil-ptr panics on its arg.

So I guess it is possible that there's a compiler bug. I'd have to grovel through some assembly.
A race could cause this, but the code in question is operating on a goroutine-local map.
Could also be a machine flake, hard to be sure. Have we seen this failure mode anywhere else?

[bcmills]

I have not seen it anywhere else. We can keep an eye on the builders and see if a pattern emerges.

[bcmills]

#42229 has a very similar failure mode.