Well I'm doing as you suggest, and I see that (using your example), I find that bio leaks. I notice that you don't tear it down, and (probably) expect SSL_free() to handle that.
I thought that the SSL session cache might have a reference open to the SSL session, so I explicitly set SSL_SESS_CACHE_OFF on the corresponding SSL context. Made no difference. Is there some way I can check the SSL reference count? I'm (warily) trying to explicitly free this bio before SSL_free, but that bothers me. -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of David Schwartz Sent: Saturday, April 18, 2009 10:04 PM To: openssl-users@openssl.org Subject: RE: tracking down memory leaks > Yeah, I think I tried that. > > But I got multiple free errors. Maybe I did it wrong. I'll try what > you suggest. What I remember was that it was wrong to delete the SSL > session (implicitly deleting the equivalent of io_bio in your > example), and then ap_bio. I didn't try deleting io_bio FIRST, then > the session, then the ap_bio. The BIO that's implicitly deleted when you free the SSL session is the bio that's the other side of the I/O bio pair. Neither the I/O BIO (the one you exchange encrypted data with) nor the SSL BIO (the one you exchange application data with) are implicitly deleted. (I'm assuming you're using BIO pairs.) Basically, this is how I do it: ssl_session=SSL_new(ssl_context); BIO_new_bio_pair(&bio, 0, &io_bio, 0); ap_bio=BIO_new(BIO_f_ssl()); SSL_set_[accept|connect]_state(ssl_session); SSL_set_bio(ssl_session, bio, bio); BIO_set_ssl(ap_bio, ssl_session, BIO_NOCLOSE); And then I tear it down as I showed. I exchange encrypted data with the io_bio and exchange application data with the ap_bio. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
