It sort of makes sense that this is a stack of certs that is left over but what confuses me is that this memory is allocated by calls executed as a result of my calling SSL_accept(ssl). Also, we're talking 253 bytes... i would imagine that stack of certs would be larger than that, wouldn't it? And shouldn't all the memory allocated by SSL_accept be freed when I call SSL_shutdown and SSL_free?
What looks suspicious to me is the calls to "x509v3_cache_extensions" that are in the traces below. This implies to me that openssl is caching something. How do I ask it to clear that cache? If i need to augment the library to do so, where are the pointers to the objects it is caching so I can free it? I tried to trace the code but got lost... i'm sure I can trace it given enough time but thought I'd ask the community first. I also note that I have no indication of any "left over memory" from my allocation of the certs that I am providing to my SSL_CTX... meaning that I believe I am cleaning my SSL_CTX and associated resources appropriately. The memory in question is definitely allocated by OpenSSL as a result of calling SSL_accept... I just need to figure out how to ask OpenSSL to free it. Thanks so much for the help. Charles A. Barbe Senior Software Engineer Allworx, a Windstream company 245 East Main St | Rochester NY | 14604 charles.ba...@allworx.com | 585.421.5565 ________________________________________ From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Dr. Stephen Henson [st...@openssl.org] Sent: Thursday, November 20, 2014 9:50 PM To: openssl-users@openssl.org Subject: Re: Small memory leak on multithreaded server On Thu, Nov 20, 2014, Barbe, Charles wrote: > Hello, > > I have noticed a small and consistent memory leak in my multithreaded openssl > server and am wondering if somebody can help me figure out what I need to do > to free it when my application closes. I am on OpenSSL version 1.0.1j. Here's > how I reproduce the leak: > > 1) Start up my server > 2) Load my homepage with Chrome > 3) Load my homepage with IE > 4) Load my homepage with Firefox > > I can do any combination of steps 2,3 and 4 above (ie. leave some of them > out) and I always get the same amount of memory left over after I shut down > my application. I believe this means that this is some sort of global > information that OpenSSL is hanging on to and not something in my SSL > connection structure. > > Specifically I get 20 blocks totaling 253 bytes. I have stack traces of where > each block is allocated but I cannot figure out how this memory should be > cleaned up. Each of the 20 blocks filter down to 1 of 5 root stack traces. > The stack traces are: > > Repeated 6 times: > 0x085c519c: asn1_item_ex_combine_new at tasn_new.c:164 > 0x085c7fd8: ASN1_item_ex_d2i at tasn_dec.c:315 (discriminator 1) > 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Repeated 6 times: > 0x085d12a4: ASN1_STRING_set at asn1_lib.c:389 > 0x085c715c: asn1_ex_c2i at tasn_dec.c:1056 > 0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836 > 0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198 > 0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7a20: ASN1_item_ex_d2i at tasn_dec.c:331 > 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Repeated 6 times: > 0x085d13bc: ASN1_STRING_type_new at asn1_lib.c:429 > 0x085c71f4: asn1_ex_c2i at tasn_dec.c:1032 > 0x085c7334: asn1_d2i_ex_primitive at tasn_dec.c:836 > 0x085c7fc8: ASN1_item_ex_d2i at tasn_dec.c:198 > 0x085c82a0: asn1_template_noexp_d2i at tasn_dec.c:734 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7a20: ASN1_item_ex_d2i at tasn_dec.c:331 > 0x085c81dc: asn1_template_noexp_d2i at tasn_dec.c:706 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Once: > 0x0866380c: sk_new at stack.c:125 > 0x0866380c: sk_new at stack.c:125 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Once: > 0x08663990: sk_insert at stack.c:151 > 0x085c8204: asn1_template_noexp_d2i at tasn_dec.c:715 > 0x085c85a0: asn1_template_ex_d2i at tasn_dec.c:616 > 0x085c7d90: ASN1_item_ex_d2i at tasn_dec.c:195 > 0x085c80a8: ASN1_item_d2i at tasn_dec.c:136 > 0x0867b368: X509V3_EXT_d2i at v3_lib.c:177 > 0x08682f3c: x509v3_cache_extensions at v3_purp.c:464 > 0x08683698: x509v3_cache_extensions at v3_purp.c:722 > (inlined by) X509_check_issued at v3_purp.c:706 > 0x0866fddc: check_issued at x509_vfy.c:417 > 0x086716d0: X509_verify_cert at x509_vfy.c:212 > 0x086967c0: ssl3_output_cert_chain at s3_both.c:387 > 0x0868ac68: ssl3_send_server_certificate at s3_srvr.c:3365 > 0x0868b864: ssl3_accept at s3_srvr.c:418 > 0x086982f4: ssl23_get_client_hello at s23_srvr.c:657 > 0x08698bb8: ssl23_accept at s23_srvr.c:213 > > Any help would be appreciated. > Not possible to be sure from that trace but at a guess I'd say a STACK of certificates hasn't been freed up. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ 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
