Hello Team, I tried to set the cache off using following command, SSL_CTX_set_session_cache_mode(sslctx, SSL_SESS_CACHE_OFF);
With this, am not seeing any memory hold. That means this memory is due to storage of ssl session information? If it is SSL session storage, when does this SSL session information will be cleared? When we do SSL_CTX_free() does this get free'd? Or Where actually this session information will be saved. Can some provide some light on this information. Any URL where this information is stored is fine. Thanks, Rajeswari. On Tue, Aug 26, 2014 at 2:08 PM, Rajeswari K <[email protected]> wrote: > Isn't CRYPTO_cleanup_all_ex_data() frees all ex_data? > > I hope the issue over here is holding the session information for > resumption is my guess. How can we disable session resumption feature > inorder not to update the session details and check whether complete memory > is freed during SSL_CTX_free() or not? > > > > > On Tue, Aug 26, 2014 at 1:31 PM, bernard Hauzeur <[email protected]> wrote: > >> A tip I got from Jeff on a similar problem, try and tell us: >> >> >> >> Bernardh>>I noted that a memory leak is left on exit of some of my >> programs if I omit to call CRYPTO_cleanup_all_ex_data() before leaving my >> DLL or other app built with openSSL. >> >> Worse, the leaked volume increases as I execute loops with more calls to >> e.g. some bio filters. >> >> Jeff>>It gets worse. If you are using Java/JNI or C#/Interop, then the >> leak accumulates each time the library is loaded/unloaded. Pretty soon, >> long lived process consume a massive amount of memory that can't be free'd. >> >> Jeff>>Compression methods in the SSL library is another offender. >> >> >> >> Bernardh >> >> >> >> *From:* [email protected] [mailto: >> [email protected]] *On Behalf Of *Rajeswari K >> *Sent:* Tuesday, August 26, 2014 9:36 AM >> *To:* [email protected]; [email protected] >> *Subject:* Memory hold issue >> >> >> >> Hello Openssl team, >> >> >> >> I have a query on the memory hold with openssl handshake. >> >> >> >> When performed openssl handshake, we are always observing memory hold >> increase. This hold eventually increases and at last we end up with device >> having no memory at all. >> >> >> >> Following is the memory hold tracebacks. >> >> >> >> First Hold : >> >> SSL_SESSION_new(0x3794200)+0x16 >> >> ssl_get_new_session(0x3793d88)+0x1e >> >> ssl3_get_client_hello(0x378bdf8)+0x1b4 >> >> ssl3_accept(0x3789590)+0x32c >> >> SSL_accept(0x3791a1c)+0x27 >> >> ssl23_get_client_hello(0x3780c12)+0x7f >> >> ssl23_accept(0x3780980)+0xe3 >> >> ssl23_read(0x3780730)+0x36 >> >> SSL_read(0x3791940)+0x3c >> >> >> >> Second Hold : >> >> sk_insert(0x375ffac)+0x52 >> >> sk_push(0x376007c)+0x17 >> >> ssl_bytes_to_cipher_list(0x3790f42)+0x102 >> >> ssl3_get_client_hello(0x378bdf8)+0x270 >> >> ssl3_accept(0x3789590)+0x32c >> >> SSL_accept(0x3791a1c)+0x27 >> >> ssl23_get_client_hello(0x3780c12)+0x7f >> >> ssl23_accept(0x3780980)+0xe3 >> >> ssl23_read(0x3780730)+0x36 >> >> SSL_read(0x3791940)+0x3c >> >> >> >> Third place : >> >> lh_insert(0x3755b3a)+0x83 >> >> SSL_CTX_add_session(0x3793914)+0x6c >> >> ssl_update_cache(0x379037e)+0x5e >> >> ssl3_accept(0x3789590)+0x1c1 >> >> ssl3_read_bytes(0x3787798)+0xb7 >> >> ssl3_read_internal(0x3786730)+0x65 >> >> ssl3_read(0x378689c)+0x1c >> >> SSL_read(0x3791940)+0x3c >> >> >> >> Fourth function : >> >> sk_new(). >> >> >> >> Please let us know whether these memory holds are for session resumption? >> or someother purpose. >> >> >> >> Is there any way we can free these memory addresses during SSL_free()? >> >> >> >> Thanks, >> >> Rajeswari. >> >> >> >> >> >> >> >> >> > >
