> The way I normally trace this stuff is to run it under a debugger first to > get the addresses of leaks then a second time with conditional breakpoints > added at those points so that when that same address is allocated it is > possible to do a stack trace to see the precise cause. > > That ex_data leak may mean you aren't calling CRYPTO_cleanup_all_ex_data(). > > Steve.
Shouldn't this memory be cleanedup automatically when I free the object that it is part of? I do understand that some things may not be deallocated if they are shared by multiple objects. The last owner of the memory would cause the refrence count to go to zero and deallocate it. The traces were generated at the time of memory allocation by our internal memory tracking code. We havn't gone as far as making it look up sybols in the source and display things really pretty. This is usually enough for us to figure out leaks in our code. Adding CRYPTO_cleanup_all_ex_data() cleanup all the leaks except for the one associated with the RSA private keys loaded into the ctxs. Shouldn't this be implicitly cleaned when the ctx is freed? At the point in the code where the ctx is freed all ssl objects have been cleaned up. I'm still concerned about the two leaks associated with the ssl object. Could these internal memory leaks build up over time (months) into something that could crash our software. Is this memory resused or cleanedup eventually? -- Walter Proseilo Bycast Inc. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
