Hi again,
I've changed the code to reuse the SSL contexts but in terms of memory
consumption/release it did not change much - if anything at all. By the
way, is there a way to "unload" a certificate once it has been loaded
into a SSL context via SSL_CTX_use_certificate() ? I didn't find
anything in the docs and simply specifying NULL as cert parameter caused
a crash in OpenSSL.
The only places left that cause memory leaks are reported inside OpenSSL
as in
at 0x68EAC8B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==27041== by 0x6C472DB: default_malloc_ex (mem.c:79)
==27041== by 0x6C4795F: CRYPTO_malloc (mem.c:306)
==27041== by 0x6C73940: bn_expand_internal (bn_lib.c:336)
==27041== by 0x6C73AE0: bn_expand2 (bn_lib.c:451)
==27041== by 0x6C73BB2: BN_set_bit (bn_lib.c:730)
==27041== by 0x6C7E16E: BN_MONT_CTX_set (bn_mont.c:514)
==27041== by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552)
==27041== by 0x6C95B56: RSA_eay_mod_exp (rsa_eay.c:782)
==27041== by 0x6C96422: RSA_eay_private_decrypt (rsa_eay.c:565)
==27041== by 0x6C97EDF: RSA_private_decrypt (rsa_lib.c:303)
==27041== by 0x6942918: ssl3_get_client_key_exchange (s3_srvr.c:2038)
==27041== by 0x6946693: ssl3_accept (s3_srvr.c:529)
==27041== by 0x69513CA: ssl3_read_bytes (s3_pkt.c:941)
==27041== by 0x694C688: ssl3_read_internal (s3_lib.c:3274)
==27041== by 0x69642E8: SSL_read (ssl_lib.c:954)
Sometimes these are flagged "still reachable" and sometimes "indirectly
lost", usually both types are reported as I get a large amount of these
traces. One thing I noticed is that all goes well if I cause the code to
run sequentially (e.g. cause requests to come one ater another). Yet it
starts eating up memory like crazy if I cause several (HTTPS) requests
to come at once.
I'm at a loss here. Valgrind insists the leaks happen in OpenSSL code.
I'll be happy to supply more information if anyone has an idea of how to
approach this.
Regards,
Thomas
On 09/13/2012 12:30 PM, Michel wrote:
Hi again Thomas,
Do you really need to free your context each time you free your TLS
session ?
I believe it is not needed and at least not usual.
If you need several *DIFFERENT* contexts, implying different TLS
configurations/setup, wich, I think, is not so common,
you can keep them 'alive' during all your app 'run', even in
multi-threaded programs.
It would allow you to access some activity informations like the ones
documented in :
http://www.openssl.org/docs/ssl/SSL_CTX_sess_number.html
Hope this helps,
Regards
Le 13/09/2012 10:39, Thomas a écrit :
Hi Michel,
Thanks for trying to help, I really appreciate it :-)
"Does your app setup and free a context each time a client is
connecting ?"
The context is created only when a client requests a HTTPS connection
and is destroyed together with the SSL session once the connection
goes down. It is rather related to connections then to clients since
one client can open several connections but I think you implied one
connection per client and then the answer is 'yes'.
I will try freeing the session before the context and come back with
the results.
Regards,
Thomas
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
