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. > > > > > > > > >
