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?

Unfreed memory is not a problem in an application, but it's a whole
different story in a library.

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.

Steven

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joshua Juran
Sent: Wednesday, 16 November 2005 12:38 PM
To: openssl-users@openssl.org
Subject: Re: SSL_library_init - missing 36 bytes after cleanup

On Nov 15, 2005, at 7:29 PM, Steven Reddie wrote:

> David,
>
> If 36 bytes are being dynamically allocated and not being freed how is 
> it not a leak?
>
> Steven

Because it only happens once.

Imagine that when you shut off a faucet, water drips out for the next ten
seconds and then stops.  That's not a leak, and it's not a problem. 
  What would be (both a problem and a leak) is water continually dripping at
a regular frequency.

The 36 bytes is not considered a leak because it's acquired only once as a
part of initialization, not proportionally to the use of your application.
And it does get released -- when the process exits. :-)

If it's a problem, maybe you should invest in a RAM upgrade...  :-D

Josh

> -----Original Message-----
> [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
> Sent: Wednesday, 16 November 2005 10:09 AM
>
>       These are 36 bytes that are consumed and used by the library. They 
> are not leaked but they cannot be freed.

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

Reply via email to