Sorry, I missed this response from Darryl Miles (probably work
spam filter being overly agressive) but found in in the archive:
> Erik de Castro Lopo wrote:
> > Unfortunately, it seems that openssl allocates memory inside the
> > call to SSL_library_init() that seems to never get deallocated.
> >
> > Would you people be interested in a patch that adds an
> > SSL_library_release() function that releases all memory and returns
> > the SSL library to the state it was in before SSL_library_init()
> > was called?
>
> Is this still true after calling:
>
> // Thread local cleanup
> ERR_remove_state(0);
>
> // Engine cleanup
> ENGINE_cleanup();
> CONF_modules_unload(1);
>
> ERR_free_strings();
> EVP_cleanup();
> CRYPTO_cleanup_all_ex_data();
Wow, I didn't know about most of those functions.
Calling these is a vast improvement but there are still a small
leak. Here's is the one and only valgrind report after doing:
int main (void)
{
SSL_library_init ();
ERR_remove_state(0);
ENGINE_cleanup();
CONF_modules_unload(1);
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();
return 0 ;
}
==31693== 48 bytes in 3 blocks are still reachable in loss record 1 of 1
==31693== at 0x401C422: malloc (vg_replace_malloc.c:149)
==31693== by 0x40A7F3D: ??? (mem.c:79)
==31693== by 0x40A84BA: CRYPTO_malloc (mem.c:304)
==31693== by 0x410BC75: sk_new (stack.c:125)
==31693== by 0x4062C4C: ??? (ssl_ciph.c:215)
==31693== by 0x4063478: SSL_COMP_get_compression_methods (ssl_ciph.c:1156)
==31693== by 0x4068591: SSL_library_init (ssl_algs.c:116)
==31693== by 0x80487C9: test_func(int) (in /home/erikd/test/ssl_memleak)
==31693== by 0x8048831: main (in /home/erikd/test/ssl_memleak)
> Maybe the problem is the confusing and non-obvious naming conventions.
>
> * Developers should be forced to call initilization code before using
> any part of the library (no implicit init).
>
> * Any initilization code should have an accompanying cleanup function
> following some arbitrary naming convention.
>
> At the moment there is a patchwork of components each with differing
> schemes (explicit or implicit initialization) and the cleanup functions
> you need to use aren't an obvious naming choice in relation to the
> init() function you called. So you have a right to be confused.
Would it help to have a function named something like
SSL_library_release() that basically calls the above functions
one by one?
Cheers,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught."
-- Oscar Wilde
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
