Add missing Dispose() call on error in MonoTlsStream.CreateStream().
#16233
Conversation
|
|
||
| try { | ||
| if (tunnel?.Data != null) | ||
| await sslStream.WriteAsync (tunnel.Data, 0, tunnel.Data.Length, cancellationToken).ConfigureAwait (false); |
There was a problem hiding this comment.
how is this even going to work given that we set sslStream = null; on line 140 above?
There was a problem hiding this comment.
If I'm following it correctly, line 140 may not be hit. At the very least, we should make sure sslStream != null.
There was a problem hiding this comment.
It will be hit if status != WebExceptionStatus.Success so unless that implies that tunnel?.Data is always null then we'll hit this (and if it does we should add a comment or the sslStream != null check to nake it clear) 😄
There was a problem hiding this comment.
I meant to say may not always be hit lol. I agree with you.
There was a problem hiding this comment.
The code may look a little bit confusing - but sslStream can never be null after the first exception block.
There was a problem hiding this comment.
It will be hit if
status != WebExceptionStatus.Successso unless that implies thattunnel?.Datais always null then we'll hit this (and if it does we should add a comment or thesslStream != nullcheck to nake it clear) 😄
The last line of the try sets status = WebExceptionStatus.Success - the only way it can have any other value is from within the catch block - and that ends with a throw. So that sslStream = null on line 140 can only happen when we're re-throwing from within the catch block.
There was a problem hiding this comment.
I see what you mean. I wonder if it would be clearer putting the two blocks into separate functions?
|
@monojenkins build failed |
|
How far back do we need to backport this? |
|
Talked with Steve, back to 2019-06 is fine. @monojenkins backport 2019-08 |
No description provided.