-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NullReferenceExceptions in OnClientSocketReceive and unhandeled SocketExceptions in async process #243
Comments
Difference between Disconnect and Socket was asked and answered on Stack Overflow Does the answer make sense to you? |
this actually crashes the whole api |
SMB2Client NBTConnectionReceiveBuffer 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.
|
Thanks, |
Hi, |
Sorry, forgot to hit the button, 1.5.1.2 is out now. |
@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. |
@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. |
@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. |
@sprehn-ero |
We use this method as a wrapper arround operations which make use of SMBClient: for example
I think implementation of EnsureDocumentFolderExists, UploadFile, RemoveAnyOtherFileInFolder is not relevant. Somehow the receiveBuffer is already released and some background task is still trying to process a response |
@sprehn-ero I tried to analyze the stack trace you provided: Getting NullReferenceException in OnClientSocketReceive when calling clientSocket.BeginReceive (in SMB2Client line 404) means that the connection buffer was disposed while receiving a packet. |
#257 was created to track the NullReferenceException issue in v1.5.13 |
The follow-up issue that has been tracked by #257 has been resolved in v1.5.2 |
Hi TalAloni,
I can confirm, that with release 1.5.1.1 the ArgumentNullException has been resolved.
![image](https://private-user-images.githubusercontent.com/106254717/302918059-ab96cc42-5116-4455-bc7e-19306e97cc5a.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQxMjAxMDksIm5iZiI6MTcyNDExOTgwOSwicGF0aCI6Ii8xMDYyNTQ3MTcvMzAyOTE4MDU5LWFiOTZjYzQyLTUxMTYtNDQ1NS1iYzdlLTE5MzA2ZTk3Y2M1YS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODIwJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgyMFQwMjEwMDlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mYjYxZGVlMjQ2ZDdlNTRhMjQxMDBjNzRiNTAwMWUzY2VhYzE2YWY5ODRiZTRhZmMxZDc2MTQ0YTEyN2NhYjk3JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9._akjlG-bV91jhF1AnW3mH-JDee5e8gF72mWENiEWjMs)
We are still seeing some NullReferenceExceptions in
![image](https://private-user-images.githubusercontent.com/106254717/302923160-50c7dfd1-c3e7-47a0-a44d-fc66d61ce811.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQxMjAxMDksIm5iZiI6MTcyNDExOTgwOSwicGF0aCI6Ii8xMDYyNTQ3MTcvMzAyOTIzMTYwLTUwYzdkZmQxLWMzZTctNDdhMC1hNDRkLWZjNjZkNjFjZTgxMS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwODIwJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDgyMFQwMjEwMDlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT01MTEwZGNlYTkyNGRjN2VhZDVhNjA0ZmQ3MDYyZGVmMGU3MzA0NDRiMWZlNDRkYzQxMjY3MzAzYzZiM2QwZjFjJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.gaDar_cD4t4UHePjBTwORWz1RsRSnLWGTvxEQf2MIUM)
void SMB2Client.OnClientSocketReceive(IAsyncResult ar)
We are also getting regularly SocketExceptions, which I am not sending to Sentry, cause it is waisting our quota.
Unfortunately I don't understand on which line, or which reference is set to null here.
I think this happens because the callback OnClientSocketReceive is still registered on the socket, even after Disconnect is called. It has somewhat todo with the Issue I raised earlier: #225 . We never found a root cause or solution to it.
Is there a specific reason you are calling Disconnect instead of Close? In line 462 close is called btw.
Documentation on BeginRecieve states this about Close (which essentially calls Dispose on the Socket):
https://learn.microsoft.com/en-US/dotnet/api/system.net.sockets.socket.beginreceive?view=net-8.0 :
The text was updated successfully, but these errors were encountered: