Devart Forums

Hi,
I just noticed that if I forcibly close a connection like for instance during a directory listing the server raises errors that the connection was forcibly closed on the remote side which is good, but the AfterClientDisconnect never fires in this case and if anything was assigned to the clientinfo.data it can't be freed up.

I have a tobject decedent assigned to the clientinfo.data and the destructor never gets called in the case a or disconnect by remote error.

is there a way to detect in the OnClientError event if the connection has dropped so the clientinfo.data can be cleaned up?

So right now if a error occurs that causes the client connection to drop anything assigned to clientinfo.data becomes a memory leak.

I am also seeing an issue where the event does fire but the clientinfo var passed in is corrupt.

The object I assigned to the clientinfo.data is showing as the correct type, but has no fields or anything in it.

I will attach some images from the debugger showing this:

Here are the images shared via goolge photos.

https://goo.gl/photos/wYWZKT6Kb7fvmCFT9

It appears if a client connection experiences some issue (and filezilla has them all the time)
The AfterclientDisconnect can sometime not fire, or when it does fire(after a client error) the
clientinfo object passed in is corrupt.

for example in the debugger the client.info.user shows as: #160#131#31

my object that I assign in the logon shows as the correct type so it passed a nil or assign check but has absolutely no fields in it.

Shows in the debugger as useobj = <TUSEROBJ> = $1f81c1 and again this passes a nil or not assigned check, but raise and exception when the code tries to access a field that is supposed to be there.

Filezilla is not that great, but it does really help in finding stuff like this.

This is really bugging me because the passed objects are actually there and pass not nil checks.

it even passes checks like this:

if clientinfo.data is tuserobject then

Thank you for the information and your help on issue investigation. The issue investigation is in progress. We will inform you when we have any results.

Victor,
There was a bug fixed way back in 2014 in regards to the AfterClientDisconnect, is it possible some regression occurred? viewtopic.php?f=27&t=30505&p=104636&hil ... ct#p104636

This is actually a two fold issue, one is that the event simply does not fire sometimes when a error occurs and sometimes it does fire on a error but the clientinfo and clientinfo.data are corrupted.

The fix you specified was related to a different problem.
We will continue investigation of the behavior of SecureBridge and inform you as soon as we get any results, but we can't tell any timeframe at the moment.

ok, thanks.
Just wanted to say with that tevent name issue fixed in the FPC compiler or by using a GUID for the tevent name the sbridge sftp server stability is greatly improved. It's just minor issues like this event not firing consistently.

I'm probably the only one using Free Pascal to compile the SFTP server LOL

We have already fixed the issue related to the event TScSSHServer.AfterClientDisconnect. This fix will be included in the next build of SecureBridge.