-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
data race on BasicHost.AutoNAT when using fsrepo.Open with core.NewNode #7947
Comments
The bug was introduced here: libp2p/go-libp2p#983 We're reading the "AutoNAT" variable from AllAddrs, and calling AllAddrs from a goroutine. |
Specifically, AutoNAT itself calls AllAddrs from within a background goroutine. |
Good find. I did think about opening an issue in go-libp2p directly, but one can argue that it's also a bug in go-ipfs until its dependency on go-libp2p is bumped after that fix. Should I open a sibling issue on go-libp2p? |
There's actually another data race I can reproduce with the exact same test code, if I comment out the code that causes the first race. It concerns go-bitswap's
|
I re-ran the test with the race detector a thousand times in parallel, and found no more races :) Thank you @Stebalien @willscott! |
The example below is a minified test from a larger real one, so please bear that in mind if it makes little sense on its own.
First, the test:
It simply initialises an empty repository in a temporary directory, and then starts a node with it. Note that the test ends shortly after, exiting the entire process.
Below is how I run it to reproduce the race:
stress
runs many processes in parallel, which helps run into the data race more quickly.Below is one of the data races I found, after just 20 or so runs:
As far as I can tell, the test code is not racy in itself, and makes valid uses of the APIs.
The text was updated successfully, but these errors were encountered: