> From: Josh Rickmar <[email protected]> > Date: Mon, 14 Sep 2020 22:48:18 +0000 > > >Synopsis: Ryzen CPUs show Go mem corruption during concurrent forking > >Category: kernel (?) > >Environment: > System : OpenBSD 6.8 > Details : OpenBSD 6.8-beta (GENERIC.MP) #0: Mon Sep 14 09:43:05 EDT > 2020 > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > > Go processes appear to show memory corruption when concurrently > fork+exec'ing, but as far as I am can tell, this only occurs on Ryzen > CPUs, making me believe it is either some kind of kernel-level issue, > or a Ryzen errata that isn't being properly dealt with. This appears > to affect all Ryzen CPUs, from first generation laptop chips all the > way up to 3000 series desktop chips. > > This was originally reported by me on the Go issue tracker, when I > discovered crashes running the Go build tests, but at the time I > didn't have the data to believe this was isolated to Ryzen systems. > > https://github.com/golang/go/issues/34988 > > I have been testing today with a kernel built at git commit > 594937660a36a61c991da10e4d9f91c8e1cdb9d0 with the amd64 cr2 fix > manually applied on top (it hadn't hit CVS nor the Git mirror then), > and am still seeing these crashes. The crash traces are not > predictable and can appear as anything from a variety of Go runtime > assertions to segfaults. > > >How-To-Repeat: > > On a Ryzen system, install 'go' from packages, save this minimal repro > to forkexec.go, and build+run it with `go run forkexec.go`: > > > package main > > import ( > "os/exec" > ) > > func main() { > sem := make(chan struct{}, 100) > for { > sem <- struct{}{} > go func() { > err := exec.Command("/usr/bin/true").Run() > if err != nil { > panic(err) > } > <-sem > }() > } > } > > > This program will concurrently execute up to 100 goroutines which > spawn a `true` process, and it will eventually crash and print > stacktraces of all goroutines to stderr. Ryzen CPUs should have many > CPU cores available, but if running this under vmm, you may need to > also set the GOMAXPROCS environment variable to something over 1 to > reproduce (untested). > > The crash output varies widely across different runs. Many crash > outputs can be seen in linked in the GitHub issue above.
I may actually have fixed that today. Please try again with tomorrows snapshot.
