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: Mon, 02 Apr 2007 18:56:40 +0100
Nitin M wrote:
Darryl, What is your opinion on this finding? As you were also keen on
knowing the result of this experimentation. :)
>>
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.
Here is my output from 0.9.7f:
--5448-- supp: 4 dl_relocate_object
==5448== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5448== malloc/free: 79 allocs, 79 frees, 2,640 bytes allocated.
No leaks, but you are testing with 0.9.8, which version?
I am testing with 0.9.8d.
I don't have time at the minute to investigate with 0.9.8.
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.
This is still true. The cleanup is an area of the library which could do
with the rough edges taking off it and the officially agreed methods to be
documented in the same place as SSL_library_init().
>> 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.
Agreed on this. A function "SSL_library_cleanup()" should be created,
which will reverse the action of calling SSL_library_init() and using the
OpenSSL library in any way possible.
Just out of curiosity I wanted to know in case any one has any Idea why was
the earlier patch submitted by Jonatahan Green was not included in
mainstream? Any specific technical reason?
It is fine by me to document that the SSL_library_cleanup() is not
thread-safe to clearly warn users to ensure they revert back to single
threaded access to the OpenSSL library for calling cleanup functions. It
should also be documented that the application code should have already
free'ed any OpenSSL objects it created and retained before calling
SSL_library_cleanup(). If should be documented that the state of the
OpenSSL library reverts to the same state as when an process first loads
the library, so the same rules apply again (i.e. its maybe necessary to
call SSL_library_init() before making use of some OpenSSL provided
functions).
It is fine by me to implement the necessary locking within the
sub-functions it calls to make those respective function thread-safe (since
there maybe legitimate reasons to call them independently of
SSL_library_cleanup() function) I think this is already done anyway.
It is fine by me for the proposed SSL_free_comp_methods() to be implemented
and also fine to remove the previously discussed first to lines from the
posted patch which attempt to reduce lock contention and locking overhead.
U mean that these lines as per the previous arguments and discusssions is
not required ?
1289 if (ssl_comp_methods == NULL)
1290 return;
You will have to petition one of the project comitters to actually get any
action on these points. Maybe posting a fresh patch which adds the above
and the necessary new documentation will help get things moving.
<rant_mode>I already have an outstanding contribution for the project that
still remains unaddressed (see postings on SSL_shutdown()) so although this
issue is something I'd normally pickup on and try to formalize (as I think
I understand the issue well enough to do that) I can only contribute as
fast as the consortium allows. My extra energy which would otherwise be
spent assisting the greater good is eaten up by maintaining a local
fork.</rant_mode>
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
_________________________________________________________________
Sign in and get updated on all the action from Formula One
http://content.msn.co.in/Sports/FormulaOne/Default
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
