Dr. Stephen Henson wrote: > On Wed, Jan 31, 2007, Ian Fette wrote: > >> Sometimes a SSL_read() operation on toClientSSL will return <0, and >> SSL_get_error yields SSL_ERROR_SYSCALL, and if I look at errno (from >> <errno.h>) it's set to EWOULDBLOCK. I had thought that if something was >> going to block, SSL_get_error would return either SSL_ERROR_WANT_READ or >> _WRITE. I was handling those two errors, but I was just assuming that >> SSL_ERROR_SYSCALL would only come up for things like premature closing >> of the socket, and other similar rather fatal errors. Is this the >> correct behavior (that it's reported as SYSCALL rather than _WANT_READ >> etc...)? >> >> Thanks in advance, and I'm sorry if this seems like a trivial question, >> but I honestly have been looking all over for an answer. >> > > One possible cause of this is an error in the queue remaining from a previous > operation. Make sure you clear the queue using ERR_clear_error() before the > call. > > Steve.
Thank you for your reply. After sleeping (always a good idea), I noticed another problem - I never defined the locking callback functions for locking via CRYPTO_set_locking_callback() etc. Defining those functions didn't fix the problem, but I can't definitively say that part of the problem wasn't related to those callbacks not having been defined. I also tried implementing your reply. Before calling SSL_read() etc I'm now calling ERR_clear_error(). Unfortunately, I still seem to be getting cases where I see SSL_ERROR_SYSCALL and errno is set to EWOULDBLOCK. Do you have any other ideas as to what the problem might be? (Or is this just behavior that I have to live with?) Thanks again for your reply, -Ian ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
