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: Wed, 21 Mar 2007 11:12:38 +0000
Nitin M wrote:
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?
If you are using SSL then you are touching many parts of the OpenSSL
library as all the digests and crypto algorithms are pulled in to allow
them to be available for selection and negotiation. Most users want to
simple few function calls to auto-register all those methods.
The simplest use of OpenSSL is more inline with how I explained, an app
just wants to use a single digest algorithm (like MD5 or SHA1, but not
SSL).
As I still maintain you need to provide information about the leak(s) in
order to progress.
Hi!
I wrote a simple program like this to find out the possibility of a memory
leak. The program goes like this.
#include<openssl/ssl.h>
int main()
{
SSL_library_init();
EVP_cleanup();
}
when I run this programm through the valgrind I get the following output.
==10036== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
--10036--
--10036-- supp: 17 Ugly strchr error in /lib/ld-2.3.2.so
==10036== malloc/free: in use at exit: 36 bytes in 2 blocks.
==10036== malloc/free: 87 allocs, 85 frees, 1472 bytes allocated.
==10036==
==10036== searching for pointers to 2 not-freed blocks.
==10036== checked 2852348 bytes.
==10036==
==10036== 36 bytes in 2 blocks are still reachable in loss record 1 of 1
==10036== at 0x1B903CC8: malloc (vg_replace_malloc.c:131)
==10036== by 0x1B978CAA: default_malloc_ex (in
/home/nitin/software/lib/libcrypto.so.0.9.8)
==10036==
==10036== LEAK SUMMARY:
==10036== definitely lost: 0 bytes in 0 blocks.
==10036== possibly lost: 0 bytes in 0 blocks.
==10036== still reachable: 36 bytes in 2 blocks.
==10036== suppressed: 0 bytes in 0 blocks.
This shows that 36 bytes in 2 block are still reachable.
In Valgrinds language "A pointer to the start of the block is found. This
usually indicates programming sloppiness. Since the block is still pointed
at, the programmer could, at least in principle, free it before program
exit." But I think these would get accumulated over a period of time if the
application uses pluggin DLLs which inturn use OpenSSL and it is not known
how often the plugin DLLs are loaded and unloaded.
After further looking into source I found that there is no way/function for
the The SSL compression methods global stack (ssl_comp_methods) to be
freed.
I added a small function SSL_free_comp_methods to cleanup this stack based
on the patch submitted by Jonathan Green.
http://marc.info/?l=openssl-dev&m=112200683926727&w=2
1287 void SSL_free_comp_methods(void)
1288 {
1289 if (ssl_comp_methods == NULL)
1290 return;
1291 CRYPTO_w_lock(CRYPTO_LOCK_SSL);
1292 if (ssl_comp_methods != NULL)
1293 {
1294 sk_SSL_COMP_pop_free(ssl_comp_methods,CRYPTO_free);
1295 ssl_comp_methods = NULL;
1296 }
1297 CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
1298 }
So when I call this function also in the application program in addition to
EVP_cleanup(),
#include<openssl/ssl.h>
int main()
{
SSL_library_init();
EVP_cleanup();
SSL_free_comp_methods();
}
the valgrind output is like this
==10055== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
--10055--
--10055-- supp: 17 Ugly strchr error in /lib/ld-2.3.2.so
==10055== malloc/free: in use at exit: 0 bytes in 0 blocks.
==10055== malloc/free: 87 allocs, 87 frees, 1472 bytes allocated.
==10055==
==10055== No malloc'd blocks -- no leaks are possible.
Which looks like a more cleaner output.
I was just wondering if this issue has been higlighted in some earlier posts
and the patch submitted looks like solving the problem, technically was
there any problem in including it into mainstream code?
Application usages goes like this:
* Application initializes the OpenSSL libary.
* Application creates and uses data object with the OpenSSL library.
* Application wants to shutdown.
* Application destroys all OpenSSL data objects it is holding.
* Application calls cleanup routines in the OpenSSL library.
This is pretty standard stuff, what David maybe highlighting is that many
programmers or a short-lived applications running on a process segmented
operating system might skip the last 2 points to save time/money.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
regards
-Nitin
_________________________________________________________________
Tried the new MSN Messenger? ItÂ’s cool! Download now.
http://messenger.msn.com/Download/Default.aspx?mkt=en-in
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
