Re: Memory Leaks in SSL_Library_init()

Sun, 01 Apr 2007 22:11:48 -0700 

Hi All!

Any inputs on this finding?
I would like to check with the core development team also, if their opinion differs on this, whether there is a need of SSL_free_comp_methods() funtion to cleanup the ssl_comp_methods? 


Darryl, What is your opinion on this finding? As you were also keen on 
knowing the result of this experimentation. :)


Thanks in advance

regards

-Nitin



From: "Nitin M" <[EMAIL PROTECTED]>
Reply-To: openssl-dev@openssl.org
To: openssl-dev@openssl.org
CC: [EMAIL PROTECTED]
Subject: Re: Memory Leaks in SSL_Library_init()
Date: Wed, 28 Mar 2007 04:14:17 +0000


     1 #include<openssl/ssl.h>
     2 int main()
     3 {
     4     SSL_library_init();
     5
     6     /* thread-local cleanup */
     7     ERR_remove_state(0);
     8
     9     /* Globals we finished with */

    10 //  
my_application_function_to_destroy_OpenSSL_objects_attached_to_local_variables();

    11     // In the particular application I am keeping an RSA
    12     // //  object around.
    13     // if(tmp_rsa != NULL) {
    14     //  RSA_free(tmp_rsa);
    15     //  tmp_rsa = NULL;
    16     // }
    17
    18
    19     // /* thread-safe cleanup */
    20      ENGINE_cleanup();
    21      CONF_modules_unload(1);
    22     //

    23     // /* global application exit cleanup (after all SSL activity 
is shutdown) */

    24      ERR_free_strings();
    25      EVP_cleanup();
    26 //   SSL_free_comp_methods();
    27      CRYPTO_cleanup_all_ex_data();
    28 }


I also tried with the above code and found that 36 bytes are still 
reachable. Then after retining only EVP_cleanup() from the clanup sequence 
of calls, I felt that EVP_clenup is doing the job of cleaning up most of 
what SSL_library_init() created.



In one of your earlier posts you have said that while you use the mentioned 
sequence of cleanup calls you did not get any memory leak at all. You dont 
even get the "Still reachable" msg with that sequence? if this is true,is 
it possible for you to post a small example code here?



Also I think the function 
my_application_function_to_destroy_OpenSSL_objects_attached_to_local_variables(); 
is your application specific function and since I did not have any RSA 
object I did not call RSA_free(tmp_rsa);



With a call "SSL_library_cleanup()", which internally calls EVP_cleanup() 
and SSL_free_comp_methods() do you see any harm or any scenario in which it 
might break. I feel that if used properly for every corresponding 
SSL_library_init(), it should not causse any problem.


What is you opinion?

Here is the valgrind output for the above program for your reference.

==10877== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
--10877--
--10877-- supp:   17 Ugly strchr error in /lib/ld-2.3.2.so
==10877== malloc/free: in use at exit: 36 bytes in 2 blocks.
==10877== malloc/free: 89 allocs, 87 frees, 1632 bytes allocated.
==10877==
==10877== searching for pointers to 2 not-freed blocks.
==10877== checked 2852348 bytes.
==10877==
==10877== 36 bytes in 2 blocks are still reachable in loss record 1 of 1
==10877==    at 0x1B903CC8: malloc (vg_replace_malloc.c:131)

==10877==    by 0x1B978CAA: default_malloc_ex (in 
/home/nitin/software/lib/libcrypto.so.0.9.8)

==10877==
==10877== LEAK SUMMARY:
==10877==    definitely lost: 0 bytes in 0 blocks.
==10877==    possibly lost:   0 bytes in 0 blocks.
==10877==    still reachable: 36 bytes in 2 blocks.
==10877==         suppressed: 0 bytes in 0 blocks.





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, 28 Mar 2007 04:53:02 +0100

Nitin M wrote:

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.



Ok, it is not clear if tried out the cleanup sequence I posted and checked 
for results after using it ?



If you are still getting leaks after; then the function 
SSL_free_comp_methods(); might be addressing a genuine leak which can't be 
reclaimed using any of the existing cleanup functions.


So I'd vote for it to get more attention and be included.


I'd also like to see a SSL_library_cleanup(), which in turn calls 
SSL_free_comp_methods() just to start the ball rolling on reducing the 
OpenSSL voodoo.


Darryl
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]


_________________________________________________________________

Spice up your IM conversations. New, colorful and animated emoticons. Get 
chatting! http://server1.msn.co.in/SP05/emoticons/


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]


_________________________________________________________________

Catch all the cricketing action right here. Live score, match reports, 
photos et al. http://content.msn.co.in/Sports/Cricket/Default.aspx


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]




























					Reply via email to