I see your point but I cannot have memory allocated when my application shuts down. This constraint is related to the fact that this is an embedded VoIP system.
Thanks for the response! 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 Viktor Dukhovni [openssl-us...@dukhovni.org] Sent: Thursday, November 20, 2014 7:26 PM To: openssl-users@openssl.org Subject: Re: Small memory leak on multithreaded server On Thu, Nov 20, 2014 at 10:19:32PM +0000, Barbe, Charles wrote: > 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: A fixed amount of memory that is not deallocated and is independent of the number of operations performed, is NOT a memory leak. Librariers to allocate memory for the lifetime of the process during one time initialization or first use of a function. This is normal. Tracking this down is a waste of time IMHO. -- Viktor. ______________________________________________________________________ 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