On Nov 15, 2005, at 9:00 PM, Steven Reddie wrote:
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.
I agree that the rules are different for shared
libraries, and if ssl
hasn't cleaned up after itself completely when the
call to
ReleaseLibrary() returns, it's a leak.
My experience with dynamically linked libraries is
limited to Mac OS'
Code Fragment Manager, where I've avoided some
issues by linking
plugins against the standard library statically, so
each one gets its
own malloc pool. I also generally work in C++,
where I can use
statically allocated objects with constructors and
destructors, such as
smart pointers.
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.
If OpenSSL claims to be usable when dynamically
loaded, then it's a bug
in OpenSSL. Otherwise, it's a bug in the code
that's loading it.
Josh
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Joshua Juran
Sent: Wednesday, 16 November 2005 12:38 PM
To: [email protected]
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
