CancellationTokenSource potential leaks in SignalR HubConnection

[leeriorio]

Describe the bug

there is CancellationTokenSource type variable in src/SignalR/clients/csharp/Client.Core/src/HubConnection.cs

aspnetcore/src/SignalR/clients/csharp/Client.Core/src/HubConnection.cs

Lines 1599 to 1600 in 257d690

	var uploadStreamSource = new CancellationTokenSource();
	connectionState.UploadStreamToken = uploadStreamSource.Token;

and in finally block of this private method only Cancel() method calls

aspnetcore/src/SignalR/clients/csharp/Client.Core/src/HubConnection.cs

Line 1704 in 257d690

uploadStreamSource.Cancel();

How about to Dispose this CTS object in finally block or add using construction in its declaration to eliminate potential memory leaks?

Found by Linux Verification Center (linuxtesting.org) with SVACE.

[BrennanConroy]

Sure, we should dispose as a good practice especially since it should be as easy as adding it after Cancel().

In this specific case there wouldn't be a leak because Cancel() disposes the internal timer and the native objects in the ManualResetEvent are wrapped in SafeHandles so are finalized. (It'd also be a super slow leak if there was one since we create one of these per connection)

[AshkanAfsharpour]

Hi @BrennanConroy, @leeriorio, and team,

I'd like to contribute to resolving this issue regarding the potential memory leak with the CancellationTokenSource in HubConnection.cs. As discussed, I plan to update the code to ensure that the CancellationTokenSource is properly disposed of after calling Cancel().

My approach will involve:

1. Adding a Dispose() call after Cancel() in the finally block to explicitly clean up the CancellationTokenSource.
2. Alternatively, I could refactor the code using a using statement around the CancellationTokenSource to ensure automatic disposal, which would be an even safer way to handle this.

Before I proceed, I wanted to check if anyone else has started working on this or if you have any preferred approach or further suggestions on how to handle this.

Thanks, and I look forward to contributing!

[BrennanConroy]

I'd probably go with the using.