The crashes are various and not consistent in their diagnostics. I've seen SIGBUS, SIGSEGV, and even the occasional SIGPROT. In general, the symptoms are diagnostic reports like the ones below. Good, small reproducers are hard to come by, but in general attempting to run the go compiler itself will very quickly crash if something is amiss. The peano test program (which lang/go-devel installs as /usr/local64/go/test/peano.go) is also known to be enough to trigger the bug on occasion (again, non-deterministically). Triggering appears slightly more likely under qemu than on real hardware, perhaps because qemu is slower by its reported wall-clock and so the runtime makes more attempts at asynchronous preemption.
If you care to try reproducing, you do not need both a Morello instance and an aarch64 instance as I did before discovering the workaround; instead, you can generate executables on Morello by running go build ... with the above workaround in place and then probe the behavior by unsetting the GODEBUG env var before running the resulting binary.
But seemingly not on aarch64 CheriBSD kernels.
Some initial debugging indicates that the crashes happen very slightly after runtime.asyncPreempt does its thing, and, indeed, disabling asynchronous preemption (
export GODEBUG=asyncpreemptoff=1) seems to remove the crashes, suggesting something slightly wrong with signal dispatch, signal handling, or the mechanism used to "inject"asyncPreemptin https://github.com/golang/go/blob/4289bd365c38a44db091396873050cab3cfa8098/src/runtime/signal_unix.go#L344-L349The crashes are various and not consistent in their diagnostics. I've seen
SIGBUS,SIGSEGV, and even the occasionalSIGPROT. In general, the symptoms are diagnostic reports like the ones below. Good, small reproducers are hard to come by, but in general attempting to run thegocompiler itself will very quickly crash if something is amiss. Thepeanotest program (whichlang/go-develinstalls as/usr/local64/go/test/peano.go) is also known to be enough to trigger the bug on occasion (again, non-deterministically). Triggering appears slightly more likely under qemu than on real hardware, perhaps because qemu is slower by its reported wall-clock and so the runtime makes more attempts at asynchronous preemption.If you care to try reproducing, you do not need both a Morello instance and an
aarch64instance as I did before discovering the workaround; instead, you can generate executables on Morello by runninggo build ...with the above workaround in place and then probe the behavior by unsetting theGODEBUGenv var before running the resulting binary.