NullReferenceExceptions in OnClientSocketReceive and unhandeled SocketExceptions in async process about smblibrary

[sprehn-ero]

Difference between Disconnect and Socket was asked and answered on Stack Overflow
https://stackoverflow.com/questions/31031835/socket-disconnect-vs-socket-close

Does the answer make sense to you?

[sprehn-ero]

dms-app  | Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.
dms-app  |    at SMBLibrary.NetBios.NBTConnectionReceiveBuffer.get_AvailableLength()
dms-app  |    at SMBLibrary.Client.SMB2Client.OnClientSocketReceive(IAsyncResult ar)
dms-app  |    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
dms-app  | --- End of stack trace from previous location ---
dms-app  |    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
dms-app  |    at System.Threading.Tasks.AwaitTaskContinuation.RunCallback(ContextCallback callback, Object state, Task& currentTask)
dms-app  | --- End of stack trace from previous location ---
dms-app  |    at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state)
dms-app  |    at System.Threading.ThreadPoolWorkQueue.Dispatch()
dms-app  |    at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
dms-app  | Aborted (core dumped)
dms-app exited with code 0

this actually crashes the whole api

[sprehn-ero]

SMB2Client
private void OnClientSocketReceive(IAsyncResult ar)
line 433 calls getter on property AvailableLength:
clientSocket.BeginReceive(receiveBuffer.Buffer, receiveBuffer.WriteOffset, receiveBuffer.AvailableLength, SocketFlags.None, OnClientSocketReceive, connectionState);

NBTConnectionReceiveBuffer
line 31
public int AvailableLength => m_buffer.Length - (m_readOffset + m_bytesInBuffer);

m_buffer must be null at this point (which means the receive buffer is already disposed at this point)

I believe it is therefore important to shutdown, and close the socket before disposing the buffer.
SMBClient2 lines 212 and 213

         m_clientSocket.Disconnect(reuseSocket: false);
         m_connectionState.ReceiveBuffer.Dispose();

[TalAloni]

Thanks,
I was not able to reproduce this, but calling Close on the socket is consistent with the server implementation, I have update the client code to invoke Close before disposing of the buffer - this change is included in v1.5.1.2, please update if there is any further issue.

[sprehn-ero]

Hi,
wanted to upgrade to 1.5.1.2 and test it, but don't find the version yet. Are you sure 1.5.1.2 is released?

[TalAloni]

Sorry, forgot to hit the button, 1.5.1.2 is out now.

[argentini]

@TalAloni I'm using 1.5.1.3 and this is still happening randomly... sometimes when I'm just recursing a directory path, or creating a file or directory. Is there a recommended way to handle the lifecycle of client requests? I've been using try/catch/finally, and disconnecting the client and then the filestore in the "finally" block.

[TalAloni]

@argentini adding information about a 1.5.1.1 issue that was already resolved and presenting it as an 1.5.1.3 issue is a sure way for miscommunication and I suspect it will not lead to any resolution.
Please create a new issue and explain exactly what are you doing and what are the symptoms and how to recreate. Thanks!

[argentini]

@TalAloni Understood. I assumed this was the same issue so I thought it made sense to add a comment here. Since the exception cannot be caught I cannot inspect it, and I'm not sure how to reproduce it. The large file read/write client examples appear to be incorrect. They use a streams but do not close the streams or declare them in a using block. So all this is why I was asking about the lifecycle. I want to make sure I'm using the library correctly to see if the issue reappears so I can try to find replication steps. Otherwise you won't stand a chance at fixing it.