The windows/386 builder crashes frequently with 

# runtime -cpu=1,2,4
exit status -1073741819
FAIL    runtime 74.823s

that's 0xc0000005, the windows "memory access violation". The test is causing
that intentionally, but it is supposed to turn into a panic, not crash the program. 

It is possible to use 'gdb -p' to attach to the broken process when this happens and
poke around.

The TestCallbackPanic tests have Go call C call Go, with the inner Go panicking and
being recovered by a defer in the outer Go. The call from C to Go pushes a new SEH, but
the panic+recovery does not pop it. This leaves the SEH pointing at memory farther down
the m stack, memory that it takes a little work to overwrite, but once it has been
overwritten, the SEH handler chain is lost, and a future hw fault will not end up in
runtime.sigtramp and Go will not handle it, and we get exit 0xc0000005.