[release/2.2] Fix CancellationTokenRegistration.Token after CTS.Dispose

[stephentoub]

CTR.Token should never throw, but it's currently throwing an ObjectDisposedException if the associated CancellationTokenSource has been disposed.

Ports #21394 to release/2.2
Fixes https://github.com/dotnet/corefx/issues/33844

[stephentoub]

Description

We added the CancellationTokenRegistration.Token property in .NET Core 2.1. Since the CTR already knows with what token it's associated, allowing you to get the token from the CTR saves you from also needing to separately store the token, which lets you improve memory utilization by not carrying it around effectively twice. We took advantage of that, for example, in FileStream's Read/WriteAsync operations, to decrease the size of the object allocated for those operations. However, the CTR.Token property is incorrectly throwing an ObjectDisposedException if the associated CancellationTokenSource has been disposed, which introduces an ODE where there wasn't previously one (just accessing a CancellationToken you already had stored). This is causing regressions in code that created a token source, registered with its token, and then disposed the source.

Customer Impact

e.g.
Exceptions on background threads that crash the process when performing operations like:

var cts = new CancellationTokenSource();
Task<int> t = fileStream.ReadAsync(..., cts.Token);
cts.Dispose();
int result = await t;

ASP.NET actually has a case of this today, e.g. dotnet/aspnetcore#4447.

Regression?

Yes. It's not a regression in CancellationTokenRegistration.Token, which was only introduced in 2.1, but rather a regression in that it's behavior isn't matching code it was used to replace, so it's for example a regression in FileStream.Read/WriteAsync.

Packaging reviewed?

Change affects System.Private.CoreLib only.

Risk

Minimal. The new code is effectively the same as the old, except avoiding a ThrowIfDisposed call.

[vivmishra]

Approved for 2.2.1.

• ASP.NET should validate if this fixes their issue.

We should wait for any 2.1 fix -- close the issue.

[muratg]

cc @halter73 @Tratcher

[halter73]

Looks reasonable.

[muratg]

@halter73 Let's verify that this fixes the customer issue (once we have a build.) Thanks.

[stephentoub]

@halter73, can you help validate it fixes the ASP.NET issue?

[halter73]

@stephentoub Sure. Are there any build artifacts I can use to test this PR or do I have to build myself?

[stephentoub]

Thanks, Stephen. Yes, e.g. on Windows:
https://ci.dot.net/job/dotnet_coreclr/job/release_2.2/job/x86_release_windows_nt_innerloop_prtest/238/artifact/bin/Product/Windows_NT.x86.Release/

[halter73]

I used the "checked" x64 artifacts from https://ci.dot.net/job/dotnet_coreclr/job/release_2.2/job/x64_checked_windows_nt_innerloop_prtest/231/artifact/bin/Product/Windows_NT.x64.Checked/.

This was easier for me since I already have the x64 SDKs installed on my workstation. I simply dropped those artifacts into $DOTNET_HOME\shared\Microsoft.NETCore.App\2.2.0\ and tested against that.

My repro app which consistently crashes with an ODE in less than a minute on the 2.2.0 runtime, didn't crash at all in 10 minutes of testing when the runtime was patched with the artifacts from this PR.

@stephentoub Is there a better way of using these artifacts for testing? If you want to try the repro yourself, it's super simple: just clone git@github.com:halter73/anc-4422.git and dotnet run.

C:\dev\halter73\anc-4422 [master ≡ +2 ~0 -0 !]> dotnet run
Hosting environment: Development
Content root path: C:\dev\halter73\anc-4422
Now listening on: https://localhost:5001
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

Unhandled Exception:
Unhandled Exception:
Unhandled Exception: System.ObjectDisposedException: The CancellationTokenSource has been disposed.
   at System.Threading.CancellationTokenSource.ThrowObjectDisposedException()
   at System.IO.FileStream.FileStreamCompletionSource.CompleteCallback(UInt64 packedResult)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
System.ObjectDisposedException: The CancellationTokenSource has been disposed.
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)   at System.Threading.CancellationTokenSource.ThrowObjectDisposedException()
System.ObjectDisposedException: The CancellationTokenSource has been disposed.
   at System.IO.FileStream.FileStreamCompletionSource.CompleteCallback(UInt64 packedResult)
   at System.Threading.CancellationTokenSource.ThrowObjectDisposedException()
   at System.IO.FileStream.FileStreamCompletionSource.CompleteCallback(UInt64 packedResult)

   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)

--- End of stack trace from previous location where exception was thrown ---
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
...

[stephentoub]

Very helpful, @halter73, thank you. I generally do something similar, patching my shared framework. I did the same here, using a locally-built release build, and no longer see the crashes that I generally saw with your repro very quickly, often within 10 seconds.