Hi All,
I agree with Steven and think that this is obviously a
leak.
I submitted a trivial patch for this a while back
which added a function that did a pop-free on the SSL
compression methods stack. It hasn't been adopted but
in my opinion it should be in order for the library to
be dynamically loadable without memory leaks.
Regards,
Jon.
--- Joshua Juran <[EMAIL PROTECTED]> wrote:
> 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: 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
>
>
______________________________________________________________________
> OpenSSL Project
> http://www.openssl.org
> User Support Mailing List
> openssl-users@openssl.org
> Automated List Manager
> [EMAIL PROTECTED]
>
____________________________________________________
Do you Yahoo!?
The New Yahoo! Movies: Check out the Latest Trailers, Premiere Photos and full
Actor Database.
http://au.movies.yahoo.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
