x/sys/unix: TestMmap crashes on openbsd/386 #21962
Description
See https://build.golang.org/log/05586e9d5271c147418b551fe2ae9026e83e5534
openbsd-386-60 at eca45997dfd6cd14a59fbdea2385f6648a0dc786 building sys at b6e1ae21643682ce023deb8d152024597b0e9bb4
? golang.org/x/sys/plan9 [no test files]
unexpected fault address 0x48381000
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x48381000 pc=0x812f319]
goroutine 14 [running]:
runtime.throw(0x817721c, 0x5)
/tmp/workdir/go/src/runtime/panic.go:606 +0x65 fp=0x18525f34 sp=0x18525f28 pc=0x806e025
runtime.sigpanic()
/tmp/workdir/go/src/runtime/signal_unix.go:383 +0x1b9 fp=0x18525f58 sp=0x18525f34 pc=0x80809f9
golang.org/x/sys/unix_test.TestMmap(0x1855e6c0)
/tmp/workdir/gopath/src/golang.org/x/sys/unix/mmap_unix_test.go:24 +0x159 fp=0x18525fbc sp=0x18525f58 pc=0x812f319
testing.tRunner(0x1855e6c0, 0x8181558)
/tmp/workdir/go/src/testing/testing.go:748 +0xa0 fp=0x18525fe8 sp=0x18525fbc pc=0x80e9c70
runtime.goexit()
/tmp/workdir/go/src/runtime/asm_386.s:1601 +0x1 fp=0x18525fec sp=0x18525fe8 pc=0x8095361
created by testing.(*T).Run
/tmp/workdir/go/src/testing/testing.go:791 +0x22b
goroutine 1 [chan receive]:
testing.(*T).Run(0x1855e090, 0x817792f, 0x8, 0x8181558, 0x80e9c01)
/tmp/workdir/go/src/testing/testing.go:792 +0x242
testing.runTests.func1(0x1855e090)
/tmp/workdir/go/src/testing/testing.go:1015 +0x45
testing.tRunner(0x1855e090, 0x18547ee4)
/tmp/workdir/go/src/testing/testing.go:748 +0xa0
testing.runTests(0x1850c0b0, 0x8229200, 0xd, 0xd, 0xffffffff)
/tmp/workdir/go/src/testing/testing.go:1013 +0x200
testing.(*M).Run(0x18554040, 0x0)
/tmp/workdir/go/src/testing/testing.go:933 +0x122
golang.org/x/sys/unix_test.TestMain(0x18554040)
/tmp/workdir/gopath/src/golang.org/x/sys/unix/openbsd_test.go:83 +0x2a
main.main()
golang.org/x/sys/unix/_test/_testmain.go:68 +0x117
FAIL golang.org/x/sys/unix 0.057s
? golang.org/x/sys/windows [no test files]
? golang.org/x/sys/windows/registry [no test files]
lIRC, it's hard to ensure that the behavior of the mprotect syscall between platforms because it depends on the implementation of virtual memory management subsystem in the kernel and the underlying peripheral stuff such as memory-management unit, and there's no guarantee that PROT_WRITE always includes PROT_READ implicitly.