Skip to content

Instantly share code, notes, and snippets.

@saurabh500
Last active May 22, 2019 01:09
Show Gist options
  • Save saurabh500/6e18564eb1a6e6889d753f9a1ff5f0e4 to your computer and use it in GitHub Desktop.
Save saurabh500/6e18564eb1a6e6889d753f9a1ff5f0e4 to your computer and use it in GitHub Desktop.
Description of Debug Assert fix

When an error occurs on the connection in case of MARS, during the execution of a reader, it forces the connection to be closed. While closing the connection the TdsParserSessionPool is Disposed

During this process of tearing down the connection, the underlying packet is released at https://github.com/dotnet/corefx/blob/e89d17a0a97d5de707f24587118acc8072667b78/src/System.Data.SqlClient/src/System/Data/SqlClient/TdsParserStateObject.cs#L2530 when the SNI error is read by TdsParserStateObject

In case of the Native SNI, the packet release also tears down any callbacks that are associated with the packet, and hence the ReadAsyncCallback is never triggered.

In case of managed SNI, the packet release sets the private SNIAsyncCallback _completionCallback to null.

My fix is to check if the _completionCallBack is null and if it is, then the upstream TdsParserStateobject is not notified of the error via the callback.

The change has been limited to the error handling part where the problems exist. There is no expectation of an unexpected successful callback being triggered after the packet has been Reset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment