Bug: Fix race condition for a read during (*dialScheduler).updateStaticPool() with a previous write on (*dialTask).resolve()#29203
Conversation
|
Thanks for reporting the race. The PR seems a bit handwavy, just adding a random lock is most probably not how this is supposed to be fixed. My guess is that there's a call order that's not supposed to happen and that needs to be fixed. |
|
CC @fjl |
|
This race was previously reported here: #23430 |
|
Looking again, the issue is more complex, because we actually do want to some other node fields from the scheduler loop. So I now think a better fix would be using |
|
Should the |
|
That would require an atomic pointer for every Enode |
|
Recreated as #29235 because I can't push to this PR for some reason. |
This PR fixes a race condition found during testing with Antithesis
The full stack trace: