You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
$ go version
go version devel +1617768d63 Tue Feb 23 14:02:33 2021 -0500 darwin/amd64
(i.e., 1.17 development)
Does this issue reproduce with the latest release?
No, since it requires a tweak to the runtime to reveal a latent bug
What operating system and processor architecture are you using (go env)?
What did you do?
Accidentally set runtime/stack.go's stackPoisonCopy to 1 in an unrelated CL that was submitted.
After this, the openbsd-amd64 builder started failing like so:
--- FAIL: TestInterfaceUnicastAddrs (0.00s)
interface_test.go:107: route ip+net: sysctl: operation not supported
--- FAIL: TestInterfaceMulticastAddrs (0.00s)
interface_test.go:134: route ip+net: sysctl: operation not supported
FAIL
FAIL net 33.868s
FAIL
go tool dist: Failed: exit status 1
The evidence suggesting that it's a flaw in the openbsd port, rather than the CL, is that this was not a CL that should have done anything to code generation in the non-experimental case; it only accidentally contained the stackPoisonCopy. After noticing this, I wrote a CL to reset stackPoisonCopy and the failure cleared. @randall77 saw the same failure in his testing after sync'ing to master; and the bug also cleared for him after he reset stackPoisonCopy.
What did you expect to see?
Not persistent failure.
What did you see instead?
Persistent failure. And it was OMG to see it clear when I reset stackPoisonCopy.
The text was updated successfully, but these errors were encountered:
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
No, since it requires a tweak to the runtime to reveal a latent bug
What operating system and processor architecture are you using (
go env
)?What did you do?
Accidentally set runtime/stack.go's stackPoisonCopy to 1 in an unrelated CL that was submitted.
After this, the openbsd-amd64 builder started failing like so:
The evidence suggesting that it's a flaw in the openbsd port, rather than the CL, is that this was not a CL that should have done anything to code generation in the non-experimental case; it only accidentally contained the stackPoisonCopy. After noticing this, I wrote a CL to reset stackPoisonCopy and the failure cleared. @randall77 saw the same failure in his testing after sync'ing to master; and the bug also cleared for him after he reset stackPoisonCopy.
What did you expect to see?
Not persistent failure.
What did you see instead?
Persistent failure. And it was OMG to see it clear when I reset stackPoisonCopy.
The text was updated successfully, but these errors were encountered: