EldoS | Feel safer!

Software components for data protection, secure storage and transfer

DataRequest memory leaks in SBSftp 4.4.88

Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.
#343
Posted: 05/30/2006 12:53:17
by Antti Karttunen (Basic support level)
Joined: 05/30/2006
Posts: 5

Hello,

I installed the newest available version of SFTPBlackbox (4.4.88, registered version) and FastMM started reporting unknown memory leaks of 26-28 bytes when I used SFTP for file transfer.

When looking at the source code in SBSftp.pas I noticed a possible reason for this. A chunk of memory is allocated with New in TElSftpClient.Read and .Write before pushing DataRequest to stack with PushDataRequest. But after retrieving the request from the stack with PopDataRequest or PopDataRequest2 the memory is not disposed. I added calls to Dispose to appropriate places in CompleteDownloadRequest, ParseStatus (both for upload and download) and ParseData. After these additions the memory leak errors disappeared, so this might be the reason for the memory leaks. Do you think my analysis is valid?

Best Regards,
Antti Karttunen
#344
Posted: 05/30/2006 13:52:11
by Eugene Mayevski (EldoS Corp.)

Thank you very much for pointing at the issue. This will be fixed immediately.


Sincerely yours
Eugene Mayevski
#425
Posted: 06/09/2006 16:24:09
by Antti Karttunen (Basic support level)
Joined: 05/30/2006
Posts: 5

I downloaded and installed the SFTPBlackBox 4.4.89 to get the new version of SBSftp.pas. However, when I tested my application with the new version, FastMM still found memory leaks. I compared the new SBSftp.pas with the
version I patched myself earlier and I found one difference in TElSftpClient.ParseStatus that might cause the leaks:

In the case of "Request = SSH_FXP_WRITE" (upload) the DataReqInfo is correctly disposed if StatusCode <> SSH_FX_OK, but if StatusCode = SSH_FX_OK, HasPendingDataRequests is called and after this the procedure exits without disposing DataReqinfo. How about enclosing the whole block after

if DataReqInfo <> nil then
...
in a try..finally clause that finally disposes the DataReqInfo regardless of the value of SSH_FX_OK? I did this and memory leaks are gone.

I also have a another question about the improved SFTP file transfers. I noticed that all my uploads resulted in corrupted files with 4.4.88 or 4.4.89. I ask the SFTPClient to send a file in blocks of $10000 bytes. When using the default upload block size ($8000 - 256 bytes) the client writes the first block correctly but after this it writes the same block again. I was able to reproduce the problem with the Eldos SFTP client sample.

When I set SFTPClient.UploadBlockSize also to $10000 bytes the problem seems to be solved. So I suppose this is a problem with the SFTP pipelining? The error occurred with OpenSSH servers 3.5, 3.6, 4.0. My SSH connection was tunneled through a commercial server from SSH (which has problems with SFTP pipelining, but here it only acts as a tunnel server to pass through firewall, so I guess it does not matter?). Downloads seem to work well with pipelining, so only the uploads are causing problems. Even if this is purely a server problem, I think it would be a good thing if both the upload and download worked correctly with all servers without any block size tweaking.

Best Regards,
Antti Karttunen
#426
Posted: 06/10/2006 04:04:12
by Ken Ivanov (EldoS Corp.)

Thank you for reporting the problem. You are quite right about object freeing, the code was fixed accordingly.

Quote
I also have a another question about the improved SFTP file transfers. I noticed that all my uploads resulted in corrupted files with 4.4.88 or 4.4.89.

Thank you for letting us know about it. We are investigating the issue at the moment, hope to prepare the fix as soon as possible.
#427
Posted: 06/10/2006 11:13:46
by Ken Ivanov (EldoS Corp.)

The problem with file upload is caused by an error in pipelining implementation. Please consider setting PipelineLength property to 1 (one) until the build that fixes the error is published.

We are really sorry for this problem.
Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.

Reply

Statistics

Topic viewed 4311 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!