Try plugging your code to exit after the first OpenSSL function, then after the second, and so forth, and see if you can get down to the simplest case.
Charles -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Thomas Sent: Monday, September 17, 2012 11:36 AM To: Michel Cc: openssl-users@openssl.org Subject: Re: Memory issues with ssl handshake 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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
