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

runtime: TestDebugCallUnsafePoint failure on noopt builder #36110

Open
bcmills opened this issue Dec 12, 2019 · 3 comments
Open

runtime: TestDebugCallUnsafePoint failure on noopt builder #36110

bcmills opened this issue Dec 12, 2019 · 3 comments

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Dec 12, 2019

--- FAIL: TestDebugCallUnsafePoint (0.00s)
    debug_test.go:220: want "call not at safe point", got %!s(<nil>)
FAIL
FAIL	runtime	23.293s

2019-12-12T17:47:19-100bf44/linux-amd64-noopt

Possibly related to async preemption?

CC @cherrymui @aclements @mknyszek @ianlancetaylor

@bcmills bcmills added this to the Go1.14 milestone Dec 12, 2019
@cherrymui

This comment has been minimized.

Copy link
Contributor

@cherrymui cherrymui commented Dec 19, 2019

I think the idea is that function debugCallUnsafePointWorker (https://go.googlesource.com/go/+/refs/heads/master/src/runtime/debug_test.go#188) does not contain any safe points after the atomic variable ready is set to 1. But this is not true for noopt build, where the atomic functions are not intrinsified and are calls (therefore safe points). I guess we should either skip the test on noopt build, or rewrite the worker function in a way that contains no calls even with noopt (I don't know how).

It doesn't seem related to preemption.

@bcmills

This comment has been minimized.

@bcmills

This comment has been minimized.

Copy link
Member Author

@bcmills bcmills commented Jan 22, 2020

Given the timing, I suspect that CL 205718 made this particular test flakier by making InjectDebugCall more likely to succeed (for #35376).

I don't think we should just skip the test on the noopt builder, since the test may also flake for non-builder users and developers using the same flags.

However, if we could detect the presence of safe points at runtime, perhaps we could skip the test dynamically.

@bcmills bcmills added the Testing label Jan 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.