Hi!
Can anyone please tell me the correct way to submit a patch here, as I have
never done that before on this list?
regards
-Nitin
From: Darryl Miles [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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 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.
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.
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_modeI 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 [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
_
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 [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
