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
