Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

openbsd-amd64 test appears to read from old stack after it is moved #44559

Closed
dr2chase opened this issue Feb 23, 2021 · 1 comment
Closed

openbsd-amd64 test appears to read from old stack after it is moved #44559

dr2chase opened this issue Feb 23, 2021 · 1 comment
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-OpenBSD

Comments

@dr2chase
Copy link
Contributor

What version of Go are you using (go version)?

$ 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.

@seankhliao seankhliao added NeedsFix The path to resolution is known, but the work has not been done. OS-OpenBSD labels Feb 24, 2021
@4a6f656c
Copy link
Contributor

4a6f656c commented Jul 3, 2022

Thanks - this was fixed via CL#366756 (4325c37) which pulled in golang.org/net/route/syscall.go from CL#366354 (golang/net@9e5a297). Resolving.

@4a6f656c 4a6f656c closed this as completed Jul 3, 2022
@golang golang locked and limited conversation to collaborators Jul 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-OpenBSD
Projects
None yet
Development

No branches or pull requests

4 participants