Race condition on synchronous call paths when timeout occurs and late remote response arrives

[procode-rd]

Hi,

I've tried quickly to create pull request with proposed fix but it seems this is not such easy as it could be :) Nevertheless, on all paths with synchronous calls in SftpSession class callbacks does not check if "timeout path" has processed in other thread and already closed wait handle through using.dispose. This leads later to receive exception with this stack (as example for initial place calling from "Exists"):

   System.ObjectDisposedException: Safe handle has been closed.
Object name: 'SafeHandle'.
   at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)
   at Interop.Kernel32.SetEvent(SafeWaitHandle handle)
   at System.Threading.EventWaitHandle.Set()
   at Renci.SshNet.Sftp.SftpSession.<>c__DisplayClass60_0.<RequestRealPath>b__0(SftpNameResponse response)
   at Renci.SshNet.Sftp.SftpSession.HandleResponse(SftpResponse response)
   at Renci.SshNet.Sftp.SftpSession.TryLoadSftpMessage(Byte[] packetData, Int32 offset, Int32 count)
--- End of stack trace from previous location ---
   at Renci.SshNet.Sftp.SftpSession.RequestRealPath(String path, Boolean nullOnError)
   at Renci.SshNet.Sftp.SftpSession.GetCanonicalPath(String path)
   at Renci.SshNet.SftpClient.Exists(String path)

When calling thread will finish with timeout (finally disposing wait handle) and response will arrive at that point, im my opinion processing of it does not make sense as library already started or is going through timeout/error path. Hence, in each place I would suggest checking this and not processing "late response" coming in. Such as:

I did not analyse TPL path (async), so that might be something to be done.

Thanks!

[Rob-Hague]

I suppose the simple way would be to catch and ignore ObjectDisposedException when calling Set. The async path uses TaskCompletionSource and would not suffer the same problem