Hi, Got over this issue.. of memory leak.. it's because of inappropriate usage of openssl library API's by glib-openssl library. ( https://mail.gnome.org/archives/commits-list/2018-September/msg06774.html ) This issue was fixed in glib-openssl libraries earlier itself.. but in our code base we didn't had this fix..
Any way. thanks you all. have a nice week ahead. -thanks harish On Sun, Jan 31, 2021 at 10:06 AM Harish Kulkarni <harishv...@gmail.com> wrote: > I am using heaptrack memory analyzer tool to track some memory leak on an > application which is using openssl as CLIENT. > One of the observations is we see constant leak with below backtrace. My > analysis has been this is to do with local caching of sessions, or some > free which we are not doing from applicable layer. > > I am doing current code changes to replace reference CRYPTO_ADD with > actually replicating the object which we can referring counting.. so that i > can know at which location we are actually referring to object(s) and then > later not freeing it up. > > Is there a easy way in OPENSSL source code to replace reference counts > with actual multiple objects allocation so that it's easy to track memory > usages.. otherwise the code is so complex for newbies to understand and fix > anything. > > > CRYPTO_malloc in mem.c:350 (libcrypto.so.1.0.0) > > asn1_enc_save in tasn_utl.c:179 (libcrypto.so.1.0.0) > > asn1_item_ex_d2i in tasn_dec.c:507 (libcrypto.so.1.0.0) > > asn1_template_noexp_d2i in tasn_dec.c:719 (libcrypto.so.1.0.0) > > asn1_template_ex_d2i in tasn_dec.c:604 (libcrypto.so.1.0.0) > > asn1_item_ex_d2i in tasn_dec.c:461 (libcrypto.so.1.0.0) > > ASN1_item_ex_d2i in tasn_dec.c:534 (libcrypto.so.1.0.0) > > ASN1_item_d2i in tasn_dec.c:154 (libcrypto.so.1.0.0) > > ssl3_get_server_certificate in s3_clnt.c:1245 (libssl.so.1.0.0) > > ssl3_connect in s3_clnt.c:351 (libssl.so.1.0.0) > > ssl23_get_server_hello in s23_clnt.c:832 (libssl.so.1.0.0) > > ssl23_connect in s23_clnt.c:231 (libssl.so.1.0.0) > > <unresolved function> in ?? (libgioopenssl.so) > > <unresolved function> in ?? (libgioopenssl.so) > > <unresolved function> in ?? (libgioopenssl.so) > > <unresolved function> in ?? (libgio-2.0.so.0) > > On Thu, Jan 28, 2021 at 10:46 PM Harish Kulkarni <harishv...@gmail.com> > wrote: > >> Hi, >> >> I keep seeing growth in memory usage.. suspecting a leak. Want to disable >> reference counting as well as stop caches so that i can isolate the issue. >> >> It's all happening on client side. I will try disabling cache.. >> >> Mean while if any other inputs/pointers would be helpful. >> >> -thanks >> harish >> >> >> On Wed, Jan 27, 2021 at 3:32 PM Matt Caswell <m...@openssl.org> wrote: >> >>> >>> >>> On 26/01/2021 18:13, Harish Kulkarni wrote: >>> > Thank you both for bringing this to my attention, your points are >>> > invaluable. >>> > >>> > If this is something which gets set from server on client side. can >>> > client override this?. Can i change this to something less and try?. >>> Has >>> > anyone tried?. >>> > >>> > Whats the option in openssl.conf or some other place?. >>> >>> The session timeout is something entirely controlled by the server. The >>> client has no influence on this*. If the server is using session tickets >>> for its sessions then it provides a lifetime hint to the client to say >>> how long the client can expect the session to be good for. The client >>> can query this using SSL_SESSION_get_ticket_lifetime_hint(). >>> >>> On the server the timeout can be configured using SSL_CTX_set_timeout(). >>> I don't think this is possible to change via openssl.conf. >>> >>> Matt >>> >>> >>> * Note that the client may be managing a cache of sessions provided by >>> servers. That's not something that happens by default in OpenSSL but can >>> be configured using SSL_CTX_set_session_cache_mode(). In that case there >>> will be separate timeouts associated with the life of the session in the >>> client cache. Those timeouts may not be the same as the server's >>> timeouts. >>> >>> > >>> > -thanks >>> > harish >>> > >>> > >>> > On Mon, Jan 25, 2021 at 11:08 PM Matt Caswell <m...@openssl.org >>> > <mailto:m...@openssl.org>> wrote: >>> > >>> > >>> > >>> > On 23/01/2021 15:22, John Thoe wrote: >>> > > Hi list, >>> > > >>> > > The session reuse question posted on the mailing list earlier >>> > > >>> > ( >>> https://mta.openssl.org/pipermail/openssl-users/2021-January/013360.html >>> ) >>> > > reminded of a somewhat similar question I have. >>> > > >>> > > As per the docs, >>> > > >>> > >>> https://www.openssl.org/docs/man1.0.2/man3/SSL_get_default_timeout.html, >>> > > it says the default value is 300 seconds for which a session >>> resuse >>> > > will be accepted. The docs say that it is the same for all >>> > > protocols. >>> > > >>> > > However I tried it with my setup where I didn't explicitly set >>> the >>> > > timeout and I am getting 7200 seconds as the default value. >>> s_client >>> > > output: TLS session ticket lifetime hint: 7200 (seconds). My >>> client >>> > > openssl.conf has no setting override (not that it should matter >>> > > because this is a server preference). No OpenSSL settings on the >>> > > server have been modified as well. >>> > >>> > Looks to me like the docs are wrong. They probably should say 7200. >>> > >>> > >>> > > >>> > > In ssl/ssl_sess.c#L80, the code matches the document: >>> ss->timeout = >>> > > 60 * 5 + 4; /* 5 minute timeout by default */ ... (with >>> additional >>> > > four seconds?) >>> > >>> > >>> > This gets set during construction and then later overwritten when >>> we >>> > actually get a new session via "ssl_get_new_session": >>> > >>> > /* If the context has a default timeout, use it */ >>> > if (s->session_ctx->session_timeout == 0) >>> > ss->timeout = SSL_get_default_timeout(s); >>> > else >>> > ss->timeout = s->session_ctx->session_timeout; >>> > >>> > In most cases SSL_get_default_timeout() calls >>> tls1_default_timeout() (it >>> > can end up somewhere different for certain protocol versions - but >>> all >>> > the different variants are the same!): >>> > >>> > long tls1_default_timeout(void) >>> > { >>> > /* >>> > * 2 hours, the 24 hours mentioned in the TLSv1 spec is way too >>> > long for >>> > * http, the cache would over fill >>> > */ >>> > return (60 * 60 * 2); >>> > } >>> > >>> > 60 * 60 * 2 = 7200 >>> > >>> > >>> > Matt >>> > >>> >>
