This is a discussion on How to Submit a patch - Openssl ; 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 >Reply-To: email@example.com >To: firstname.lastname@example.org >Subject: Re: Memory Leaks in SSL_Library_init() >Date: ...
Can anyone please tell me the correct way to submit a patch here, as I have
never done that before on this list?
>From: Darryl Miles
>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-- 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== 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
>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
>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
>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.
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
>OpenSSL Project http://www.openssl.org
>Development Mailing List email@example.com
>Automated List Manager firstname.lastname@example.org
Tried the new MSN Messenger? Itís cool! Download now.
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org