Hi Again, I've been looking into the below further and if it is a leak then I think the neatest solution isn't to create a separate free function for the compression methods stack, but to free it in EVP_cleanup() in the exact same manner that the ciphers and digests that are dynamically created in SSL_library_init() are freed there also.
> Hi List, > > I think that the dynamic allocation of the global > stack of compression methods (ssl_comp_methods) > during > SSL_library_init() which doesn't have a > corresponding > free causes a memory leak. > > I can see that around where this is allocated in > load_builtin_compressions(), memory checking is > turned > off and on, which leads me to believe that the > creator > of this code considered this to be a once of > allocation and not a leak. > > This may be true for the scenario where the ssl > library is loaded and initialised once for the life > of > a process. However, in a scenario where the ssl > library is repeatedly loaded, initialised, and > unloaded within a single process, wouldn't this > allocation would occur every time or am I missing > something? > > If this is a memory leak, then I'd be willing to > submit a patch with some kind of > SSL_free_comp_methods() function. > > Thanks, > Send instant messages to your online friends http://au.messenger.yahoo.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
