Hi Thomas,
I don't know if it makes a real difference concerning memory leaks,
but I would have freed the TLS session *BEFORE* freing the context :
SSL_free(ssl);
...
SSL_CTX_free(ssl->ctx);
Does your app setup and free a context each time a client is connecting ?
Le 12/09/2012 16:58, Thomas Eckert a écrit :
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
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
