On Thu, Jul 03, 2003, Walter Proseilo wrote:
> I'm currently using openssl to provide TLS support for our software. We have
> our own networking implemtation using the Linux (unix) networking commands.
> This deos error handling, buffering, blocking etc.
>
> The TLS implimentation uses the networking implimentation to communicate with
> remote hosts. It does not have direct access to the socket (fd) so it uses a
> bio pair to send data to and from the network implimentation.
>
> We have our own memory management and tracking library which we have hooked
> into open ssl. When the a program is shutting down our memory will display
> the memory leaked and stack trace for its allocation. Using this I have
> found two memory leaks for every connection that I can't seem to clean up.
> This was observed in 0.9.7a and 0.9.7b versions of openssl.
>
> //the code for creation of the ssl object is as follows.
> ConnectionInfo->ssl = SSL_new(ctx);
>
> //create BIO pair
> size_t bufsize = BIOPAIRBUFFSIZE;
> BIO_new_bio_pair(&(ConnectionInfo->internal_IO), bufsize,
> &(ConnectionInfo->external_IO), bufsize)
>
> //set input/output BIOs for ssl object
> SSL_set_bio(ConnectionInfo->ssl,
> ConnectionInfo->internal_IO,
> ConnectionInfo->internal_IO);
>
> //set connect/accept state
> if(ConnectionInfo->isserver == true)
> {
> SSL_set_accept_state(ConnectionInfo->ssl);
> }
> else
> {
> SSL_set_connect_state(ConnectionInfo->ssl);
> }
>
> //start handshake
> int ret = SSL_do_handshake(ConnectionInfo->ssl);
>
> The code for clean up of the object after shutdown has been sent and recivied
> is as follows.
>
> //free SSL structures
> SSL_free(conninfo->ssl);
> BIO_free(conninfo->external_IO);
>
> >From reading the documentation all other structures and memory should be
> implicitly cleaned up when I free the ssl object.
>
> One leak has to do with the bio pair. Both bios in the pair are deallocated
> when the TLS interaction is complete. The implimentation is the same as that
> described in the example on man page for BIO_new_bio_pair.
>
> Stack trace is as follows.
>
> //our memory allocator
> (mymalloc__FUi+0x1e) [0x80b2c5a]
> [0x8104b76]
> (CRYPTO_malloc+0x6d) [0x81050e5]
> (sk_new+0x3d) [0x8112311]
> (sk_new_null+0x10) [0x81122c4]
> [0x8106771]
> [0x8106a5e]
> (CRYPTO_new_ex_data+0x2e) [0x810718a]
> (BIO_set+0xa6) [0x810ba4a]
> (BIO_new+0x56) [0x810b976]
> (BIO_new_bio_pair+0x2b) [0x8111e27]
> //Our program stack
>
> The second memory leak is in the handshake. It is usually 16 bytes in size.
> stack trace is as follows.
>
> //our memory allocator
> (mymalloc__FUi+0x1e) [0x80b2c5a]
> [0x8104b76]
> (CRYPTO_malloc+0x6d) [0x81050e5]
> (sk_new+0x3d) [0x8112311]
> (sk_new_null+0x10) [0x81122c4]
> [0x8106771]
> [0x8106a5e]
> (CRYPTO_new_ex_data+0x2e) [0x810718a]
> (SSL_SESSION_new+0xdf) [0x80f0533]
> (ssl_get_new_session+0x1a) [0x80f05c6]
> [0x80fbe1f]
> (ssl3_connect+0x406) [0x80fb60a]
> (SSL_do_handshake+0x9f) [0x80ee3f3]
> //Our program stack
>
> Is there any way to clean up these memory leaks? Is there something that I
> missed or forgot to do?
>
> In addition there are a number of onetime initilization memory leaks. They
> all appear to be data that is associated with the ctxs when they are
> initilized. Certtificates, Certificate authorities and Private Keys. Each
> ctx is freed at during cleanup before the program completes.
>
The way I normally trace this stuff is to run it under a debugger first to get
the addresses of leaks then a second time with conditional breakpoints added at
those points so that when that same address is allocated it is possible to do
a stack trace to see the precise cause.
That ex_data leak may mean you aren't calling CRYPTO_cleanup_all_ex_data().
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
