> 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]
