Question

CPU usages goes to 99% for following scenario.
1.Try to connect with Easy proxy server by configuring Socks v4/5
2.Enter wrong IP address for ftp details
3.Try to connect
4.Wait for few seconds and in between dispose ftp obj and close the form 5.Do not close application.
6.Observe that the CPU usages go high to 99%
7.Use following code

public partial class TestForm : Form
{
    private Ftp _ftp;
    private Thread _thread;

    public TestForm()
    {
        InitializeComponent();
        _ftp = new Ftp();

        // Using Easy Proxy server; proxy details are correct.
        _ftp.Proxy = new FtpProxy(FtpProxyType.Socks5, "192.168.1.143", 1080, new NetworkCredential("a", "a"));
    }

    private void TestForm_Load(object sender, EventArgs e)
    {
        _thread = new Thread(Start);
        _thread.IsBackground = true;
        _thread.Name = "MyThread";
        _thread.Start();
    }
    private void Start()
    {
        try
        {
            //TODO :  enter incorrect IpAddress of FtpServer.
            _ftp.Connect("192.168.1.14", 21);
            _ftp.Login("testuser", "testuser");
        }
        catch (FtpException ex)
        {
            Console.WriteLine("error msg= " + ex.Message);
        }
    }

    private void btnClose_Click(object sender, EventArgs e)
    {
        _thread.Abort();

        //i tried using disconnect method but i am getting AnotherOperationPending Exception.
        // _ftp.Disconnect();

        _ftp.Dispose();

        Close();
    }
}

What is the best method to abort Connect method.

Comments

Hello, there are a few priority support requests in our mailbox that I have to solve first. If you have an active support contract, please send me your registered email to support@rebex.net and I will treat your request with more priority.

Answer 1

UPDATE:

The fix has been released as part of Rebex FTP/SSL version 2016 R1.

---

Hello,

thank you for your test app that we received via email. Using the test app we discovered it was actually a serious bug in Rebex components. Thanks for bringing this issue into our attention.

The bug is caused by an erroneous code in Socket4/Socket5 response reading code that is missing a check for closed connection and basically looks like this:

   while (n < 8)
   {
          while (socket.Available == 0)
          {
                 Thread.Sleep(1);
          }

          n += socket.Receive(reply, n, 8 - n);
   }

Thread.Sleep prevents the loop from wasting CPU cycles before the timeout exception occurs, but when the socket is closed, the Receive method indicates this by returning zero, which triggers an infinite loop. And because the proxy connection code runs in a background thread, it keeps running even when the exception is thrown because the Receive method usage is wrong.

Surprisingly, this bug has been in our proxy code since the first release of Rebex FTP/SSL (called Rebex Secure FTP back then) in 2003, so it’s quite surprising it was only revealed now. This is mostly due to a fact that most Socks4/Socks5 proxies actually do return a response indicating a failure before closing the connection.

Interestingly, this code was left in our Socket4/Socket5 implementation by mistake. Calling Socket.Available is a very bad idea performance-wise and we removed all occurrences of it from our code a long time ago, but forgot to remove this one.

We will fix this and send you a link to a hotfix. Sorry for inconvenience!
This fix has been released as part of Rebex components 2016 R1.