-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Fix potential Debug.Assert in QuicListener #103965
Conversation
Tagging subscribers to this area: @dotnet/ncl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
can we craft test that would cause the timeout predictably? |
we have a test for timeouts, but this the failure happened because the timeout ran out at the same time we got connection shutdown notification from MsQuic so it was effectively a data race. I don't see a way to craft a test for this (I tested this by adding extra waits and other changes to trigger the exact failure condition). |
/ba-g failures are either known or unrelated (wasm library build errors) |
Fixes #103911.
The reason the crash happened is that both
linkedCts
andconnection.ConnectionShutdownToken
fired. The code checkedConnectionShutdownToken
first, assuming that the connection close because peer closed it during the handshake, but the reason for the exception was actually because theHandshakeTimeout
ran out, so the control flow shouldn't have entered that catch block in the first place.Checking that
linkedCts
has not been signalled yet eliminates the race.