Hi! All,
Thanks very much for your inouts on this.
From: Darryl Miles <[EMAIL PROTECTED]>
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
Subject: Re: Memory Leaks in SSL_Library_init()
Date: Tue, 20 Mar 2007 17:18:40 +0000
David Schwartz wrote:
The function SSL_library_init() is observed to be introudcing
memory leak in
the application code. There is still some amount of memory leak left even
after the series of cleanup calls suggested in the openssl FAQ.
Can someone help understand that technically what is the problem
in having a
single cleanup call like SSL_library_cleanup, instead of a using
a series of
cleanup calls?
Because there are multiple layers in use at the same time. Think of
OpenSSL more as a collection of cryptographic functions bundled together
rather than a single entity.
OpenSSL is able to load dynamically at runtime additional functionality and
allow the application to provide functionality to hook in. For example I
could expose a bespoke homebrew digest or encryption algorithm in such a
way that it could be negotiated via SSL.
At the other end of the scale there are users who simply want to use
OpenSSL to provide just a single digest algorithm, and consequentially
don't need all the extra initialization for SSL support.
Does this mean that in such scenario the application need not call
SSL_library_init since it does not need those extra initialisations and can
achieve only the required initialisations with specific calls?
If this is true I have two more questions here,
1. In what scenario then an application should use SSL_library_init()? I
think not for the simplest use of SSL/Crypto functionality in the
application.
2. If SSL_library_init() should be called only once in the lifetime of a
process and it is is creating some global data structures only once within
that process, why cant we have a function to clear all these global
variables which can be called at the the process termination time?
Out of interest where are those memory leaks that you find ?
As for the series of cleanup calls, there are several reasons. The two
main
ones are that you might need to cleanup different things and some cleanup
functions need to be called from a particular context.
I'm not heard the argument that doing correct cleanup introduces extra code
complexity in relation to OpenSSL. David seems to be providing generic
reasons why this leak might exist as opposed to the reasons for this
specific leak you have found.
Sure I can think up many reasons why this leak exists, at the top of my
list would be, "maybe there is a genuine bug here that the developers dont
know about it yet".
So I'd like to continue on the path to proving or disproving that by asking
the O/P'er to specify what exactly he has found that is being leaked.
valgrind can be a useful in this regard, but dont forget to compile OpenSSL
with -DPURIFY or disable uninitialized data checking.
Despite what the man page / FAQ suggests you should do, would it be
possible to try the following cleanup sequence and confirm if this changes
the situation with your leaks:
/* thread-local cleanup */
ERR_remove_state(0);
/* Globals we finished with */
my_application_function_to_destroy_OpenSSL_objects_attached_to_local_variables();
// In the particular application I am keeping an RSA
// object around.
// if(tmp_rsa != NULL) {
// RSA_free(tmp_rsa);
// tmp_rsa = NULL;
// }
/* thread-safe cleanup */
ENGINE_cleanup();
CONF_modules_unload(1);
/* global application exit cleanup (after all SSL activity is shutdown) */
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();
Last time I run my application through valgrind I did not have any leaks
with my OpenSSL usage.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
regards
-Nitin
_________________________________________________________________
Watch free concerts with Pink, Rod Stewart, Oasis and more. Visit MSN
Presents today.
http://music.msn.com/presents?icid=ncmsnpresentstagline&ocid=T002MSN03A07001
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]