Sure, that's a contrived and extreme example, but the best way to illustrate such a leak. For long-running (24x7) servers that may consist of many components and subcomponents this scenario can occur. With large enterprise server applications that are built with processes that value component re-use it's effectively impossible to know how some low-level subcomponent is implemented. While excessively loading and unloading DLLs may be less efficient, a 36 byte leak occuring frequently enough will bring down a server in time.
I disagree with it being prohibitively expensive to eradicate such leaks. Yes it takes some effort, but a library-lifetime structure to house such "global" dynamically allocated data, or a cleanup callback registration scheme, makes it trivial to release it all when appropriate. I guess it depends on how much you value leak-free code. For me it's a needle-in-a-haystack problem; that every "one-off" leak has the potential to mask real leaks and make using leak detection tools such as Purify and BoundsChecker less fruitful. Steven -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz Sent: Wednesday, 16 November 2005 3:02 PM To: openssl-users@openssl.org Subject: RE: SSL_library_init - missing 36 bytes after cleanup > I understand about one-off leaks, but we're talking about a > dynamically loadable library when we're talking about OpenSSL. > What would happen if an application did something like this: > > for (int i=0; i<1000; i++) > { > hSSL = LoadLibrary("libssl.so") > fn = GetSymbol(hSSL, SSL_COMP_get_compression_methods); > fn(); > ReleaseLibrary(hSSL); > } > Is it still a one-off leak? It is often effectively impossible to fully clean up without destroying the process. It may be a good goal to aim for, but it is by no stretch of the imagination a requirement. I would argue that an application that did something like that is broken. If you plan to reuse a library soon, unloading it and reloading it is broken. > Unfreed memory is not a problem in an application, but it's a whole > different story in a library. Nevertheless, perfectly freeing everything is not always possible and not always worth the effort. In this particular case, it is a trivial bug. > Another example of such problems in libraries is atexit(). atexit() > works great in an application, but use it in libssl.so when used in > the code above and you'll most likely get a hard crash when the > application terminates because the handler is still registered with > the C runtime library, but the code has been unloaded. It really depends upon what types of use the library is supposed to support. Not every library claims to be suitable to use this way and for some problems, it's simply prohibitively expensive to make them do so. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
