If you expect no more data from the client, you can simply destroy the SSL context at the point you first call it (even if it returns 0). It will only return 1 if it has received the peer's close_notify, and it's possible that those peers failed to send it. (Do you get an SSL_ERROR_SYSCALL with EINVAL or EPIPE?)
-Kyle H On Thu, May 14, 2009 at 7:31 AM, Andy Murphy <an...@tbsmobility.com> wrote: > Hi, we are trying to track down a memory leak that occurs when we run secure > comms using the OpenSSL library. Now we’ve had this before where we thought > it was the library but I tracked it down to us not using the word virtual on > our base class’ destructor, so I’m not about to start blaming OpenSSL again > J. > > > > I have however seen from some other threads that if SSL_shutdown does not > return 1 then there could be a leak. Our logs show that two attempts to > call SSL_shutdown do not result in 1 coming back and I’ve just tried it in a > never-ending while loop and well, it never ended, suggesting that we are > doing something wrong. > > > > Do we know what SSL_shutdown depends on in order to be able to shutdown > correctly and thus free the memory used for the connection? > > > > Cheers > > > > Andrew Murphy > > Senior Software Developer > > Ironstone House, Kedleston Close, Belper, > > Derbyshire, England DE56 1TZ > > Office Reception: +44 1773 596900 > Fax: +44 1773 596901 > > Skype: andyleemurphy > Web: www.tbsmobility.com > Email: andrew.mur...@tbsmobility.com > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org