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
{{ message }}
This repository was archived by the owner on Dec 7, 2019. It is now read-only.
Ok, so the RACE is an artefact of the test (it's not in the code under test itself).
These lines both invoke the t *testing.T struct at the same time, leading to a data race.
go-libp2p-transport@v0.0.1/test/stream.go:52
^ error during fullClose()
^ invoked in post-test cleanup (defer)
go-libp2p-transport@v0.0.1/test/stream.go:355
^ since fullClose never ends, the waitgroup is never done, and a timeout fires,
which also attempts to fail the test
Ok, found the issue. The affected test (SubtestStreamOpenStress) has a 10 second timeout. The race checker adds considerable overhead, sending the runtime of these tests way above 10 seconds. As a result, the test times out and begins cleanup while the workers are still running on separate goroutines. Increasing the timeout to 30 seconds was enough. I'll increase to 1 minute to be on the safe side, though. We know these tests succeed, so the tradeoff of waiting a minute for a real failure seems fair to me.
raulk
transferred this issue from libp2p/go-tcp-transport
Mar 1, 2019
Even though there's a race, the race detector somehow provokes a test failure by panic:
(race flag was enabled in transports using the test suite herein: libp2p/go-tcp-transport#34 libp2p/go-ws-transport#40)
The text was updated successfully, but these errors were encountered: