shutdown() can raise an "empty" exception

[Giampaolo Rodolà]

Where by "empty" I mean:

ipdb> err
Error([],)
ipdb> err.args
([],)
ipdb> err.message
[]

This comes from a user who reported a bug on pyftpdlib issue tracker:
http://code.google.com/p/pyftpdlib/issues/detail?id=171

The problem appears to be here:

    MY_BEGIN_ALLOW_THREADS(self->tstate)
    ret = SSL_shutdown(self->ssl);
    MY_END_ALLOW_THREADS(self->tstate)

    if (PyErr_Occurred())
    {
        flush_error_queue();
        return NULL;
    }

The right way to handle this, IMO, would be to avoid calling PyErr_Occurred() / flush_error_queue() at all and check SSL_shutdown return code and then call SSL_get_error() instead.

If SSL_get_error() returns SSL_ERROR_NONE (as in this case) it would make sense to just return Py_False.
For the upper application this means that Connection.shutdown() must be called again in order the complete the shutdown process (note: I'm using non blocking sockets).

[Jean-Paul Calderone (exarkun)]

From discussion on IRC, this is probably because of the handling of `ret < 0` case. SSL_shutdown doesn't seem to push any errors into the queue, instead you're supposed to interpret the return value as an error code.

[Jean-Paul Calderone (exarkun)]

Hm. However, I can't reproduce the problem. It appears as though SSL_shutdown *does* push the error into the queue, and that the return value of SSL_shutdown is *not* supposed to be interpreted as an error code: -1 merely indicates an error occurred, not what the error was. Looking through the OpenSSL 0.9.8g and 1.0.0a source code doesn't reveal any obvious contradiction to this. In fact, it seems as though the only way SSL_shutdown can fail at all is if it is called before a handshake has completed. So, I'm at a loss as to the cause of this problem.