> Hmm. I wrote the manual page and I am somehow convinced that it is > correct. Whenever SSL_free() is called, the underlying BIO is also > free()ed. As a BIO pair consists of 2 BIOs, only one BIO is freed > automatically, the other one has to be handled by the application. > Are you sure that both BIO objects are left after SSL_free()? > > Best regards, > Lutz
I'm pretty sure that both BIO objects are left after the SSL_free(). I originally implimented the code just like the example in the man page. When we pluged our memory alocation/tracking code into openssl we found several leaks. At that time I was only deallocating the external bio as per the example. There were several leaks related to the bio pair. It appeared that the internal bio and its buffer were being leaked. This leak was cleaned up by adding a call to deallocate the internal bio. I do not get a segfault or anything to indicate that the block was already dealocated. To create and set the bio pair I do the following BIO_new_bio_pair(&ConnInfo->internal_IO, buffsize, &connInfo->external_IO, buffsize); SSL-set_bio(ConnInfo->ssl, ConnInfo->internal_IO, ConnInfo->internal_IO); I currently make the following calls every time I clean up a ssl object SSL_free(ConnInfo->ssl); BIO_free(ConnInfo->external_IO); BIO_free(ConnInfo->internal_IO); //added to clean up leak Seems very similar to the example except for the eallocation of the internal bio. Code handles multiple connections, the ConnInfo variable is retrieved from a table of connections when data is read or written to ssl object. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
