-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Data race when calling assert.Eventually() #865
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
Labels
assert.Eventually
About assert.Eventually/EventuallyWithT
bug
pkg-assert
Change related to package testify/assert
Comments
Today, I found sometime and managed to reproduce the issue. Build$ go build -race Eventually.go Eventually.go
package main
import (
"time"
"fmt"
)
func main() {
f := func() bool {
time.Sleep(100 * time.Millisecond)
return true
}
fmt.Printf("Eventually result is %v\n", Eventually(f, 100 * time.Millisecond, 1 * time.Millisecond))
}
func Eventually(condition func() bool, waitFor time.Duration, tick time.Duration) bool {
timer := time.NewTimer(waitFor)
ticker := time.NewTicker(tick)
checkPassed := make(chan bool)
defer timer.Stop()
defer ticker.Stop()
defer close(checkPassed)
for {
select {
case <-timer.C:
return false
case result := <-checkPassed:
if result { return true }
case <-ticker.C:
go func() {
checkPassed <- condition()
}()
}
}
} Data Race
Solution?I think If you simply remove the following statement defer close(checkPassed) There would be no data race and/or panic due to sending to a closed channel, the channel should eventually (when the goroutines with the conditions finish) be garbage collected, there is no need to close the channel on return. |
This was referenced Jul 6, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
assert.Eventually
About assert.Eventually/EventuallyWithT
bug
pkg-assert
Change related to package testify/assert
Uh oh!
There was an error while loading. Please reload this page.
Hi,
Today I realize that one of my tests is flaky, working most of times but failing others with a data race being reported.
I'm using
github.com/stretchr/testify v1.4.0
I have the impression that the following return causes the function to exit and close
checkPassed
channel.testify/assert/assertions.go
Lines 1486 to 1487 in 221dbe5
Which is still being targeted by the following goroutine.
testify/assert/assertions.go
Lines 1493 to 1495 in 221dbe5
This would only happen when the goroutine with
condition()
is running but not finish yet, and the timer hits causing the return close.Assuming I'm right I'm not sure yet what's the best way to fix it, may be decoupling those two into different select and using more channels, or may be there is some trick to not try to send if the channel was closed/deallocated, I would happily create a PR once/if in agreement...
Here is the data race trace.
Thanks!
The text was updated successfully, but these errors were encountered: