Not sure if it help at all but FWIW I am using Windows pre-built OpenSSL dll's with server & client certificates, CAs, DH keys, and a CRL, and I am seeing no memory leaks whatsoever in Visual Studio 2010.
Charles -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Thomas Eckert Sent: Wednesday, September 12, 2012 7:59 AM To: openssl-users@openssl.org Subject: Memory issues with ssl handshake Hi, Valgrind gives me a *lot* of messages like this ==19021== 2,056 bytes in 2 blocks are indirectly lost in loss record 186 of 190 ==19021== at 0x68EAC8B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==19021== by 0x6C472DB: default_malloc_ex (mem.c:79) ==19021== by 0x6C4795F: CRYPTO_malloc (mem.c:306) ==19021== by 0x6C73940: bn_expand_internal (bn_lib.c:336) ==19021== by 0x6C73AE0: bn_expand2 (bn_lib.c:451) ==19021== by 0x6C73BB2: BN_set_bit (bn_lib.c:730) ==19021== by 0x6C7E16E: BN_MONT_CTX_set (bn_mont.c:514) ==19021== by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552) ==19021== by 0x6C97053: RSA_eay_public_decrypt (rsa_eay.c:693) ==19021== by 0x6C97F1F: RSA_public_decrypt (rsa_lib.c:309) ==19021== by 0x6C98BEB: int_rsa_verify (rsa_sign.c:182) ==19021== by 0x6C98F57: RSA_verify (rsa_sign.c:284) ==19021== by 0x6949E16: ssl3_get_key_exchange (s3_clnt.c:1562) ==19021== by 0x694BF5F: ssl3_connect (s3_clnt.c:335) ==19021== by 0x6964AB9: SSL_connect (ssl_lib.c:933) ==19021== by 0x6953FDD: ssl23_connect (s23_clnt.c:693) ==19021== by 0x6963FBC: SSL_do_handshake (ssl_lib.c:2368) ==19021== by 0x8060D14: ssl_connect (ssl.c:1078) Compared to the above they vary only in one line, e.g. ==19021== 1,024 bytes in 2 blocks are indirectly lost in loss record 181 of 190 ==19021== at 0x68EAC8B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==19021== by 0x6C472DB: default_malloc_ex (mem.c:79) ==19021== by 0x6C4795F: CRYPTO_malloc (mem.c:306) ==19021== by 0x6C73940: bn_expand_internal (bn_lib.c:336) ==19021== by 0x6C73AE0: bn_expand2 (bn_lib.c:451) ==19021== by 0x6C73D53: BN_copy (bn_lib.c:506) ==19021== by 0x6C7DFCA: BN_MONT_CTX_set (bn_mont.c:421) ==19021== by 0x6C7E402: BN_MONT_CTX_set_locked (bn_mont.c:552) ==19021== by 0x6C97053: RSA_eay_public_decrypt (rsa_eay.c:693) ==19021== by 0x6C97F1F: RSA_public_decrypt (rsa_lib.c:309) ==19021== by 0x6C98BEB: int_rsa_verify (rsa_sign.c:182) ==19021== by 0x6C98F57: RSA_verify (rsa_sign.c:284) ==19021== by 0x6949E16: ssl3_get_key_exchange (s3_clnt.c:1562) ==19021== by 0x694BF5F: ssl3_connect (s3_clnt.c:335) ==19021== by 0x6964AB9: SSL_connect (ssl_lib.c:933) ==19021== by 0x6953FDD: ssl23_connect (s23_clnt.c:693) ==19021== by 0x6963FBC: SSL_do_handshake (ssl_lib.c:2368) ==19021== by 0x8060D14: ssl_connect (ssl.c:1078) The application in question is a http proxy and is leaking memory heavily. Actually, Valgrind also reports many entries as "still reachable" instead of "indirectly lost" but even those regions are mentioned by Valgrind like the above two blocks. I doubt OpenSSL has such blatant memory leaks but I have been searching for the leaks for some time now and just cannot find anything - also due to the fact that Valgrind reports all the leaks like above, which is not really helpful. I do realize that for detailed help I would need to give some code on how the connections are set up but that code is pretty large. So best would be some hint as to where to look for or what regions of code to supply. Looking for hints as to what is going wrong I went through some of the OpenSSL functions mentioned above and after "leaving my code" and entering OpenSSL code the only thing being passed around the functions is the actual SSL object - and no buffers of any kind. So I suppose the source of the problem lies in setting up the object, it's context or what ever is stuck to it. The first thing I checked on was how the SSL connections are torn down in my application: ERR_remove_state(0); SSL_CTX_free(ssl->ctx); SSL_free(ssl); The first line was added only after starting the search for the leaks and I'm still not sure if that line doesn't break anything. I did find some minor leaks in my code along the way (e.g. a forgotten ASN1_INTEGER_free()) but they were neither easy to find - because Valgrind also reported them like the above two blocks, meaning in the wrong place! - nor did they change much. Does anyone have some tips for me ? ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
