curl-library
Re: Proposed fix for OpenSSL memory leaks.
Date: Fri, 11 May 2012 09:16:37 +0200
Hi,
basically, the only good thing you can do is provide (as curl does) a
cleanup function which calls the curl cleanup call (which should call
the OpenSSL cleanup function). You cannot and should not do it, as you
might cleanup e.g. openssl data still in use by the program.
Even then, cleaning up openssl is hard.
Are you sure the 36 bytes really increase, i.e. if you would call your
library twice do you get 72? What you could try is write a binary that
calls your library a number of times, then do a curl_global_cleanup
after that and see how much you have left. It might be that it's a
constant leak in the global openssl data and stays at 36.
Cheers,
Mischa
On Thu, May 10, 2012 at 06:34:44AM -0700, JonathonS wrote:
> Thanks guys for the feedback. It's very informative. So the problem
> I am having then is that I am deploying my code to customers as a
> dynamic library (DLL on windows, SO on linux). When my library is
> unloaded, I invoke the global cleanup function for curl. My customers
> can potentially continuously load/unload my library which means that
> the global init and global cleanup functions will be invoked several
> times -- one for each load and unload. Each time my library is being
> unloaded, my debugger reports a memory leak of 36 bytes. I am
> assuming this is caused by the "global table" in OpenSSL.
>
> Has anyone encountered this problem? Is this really a memory leak in
> OpenSSL or is the debugger confused? If so, what is the suggested
> approach for fixing this?
>
> thanks!
>
> J
>
> On Thu, May 10, 2012 at 4:10 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> > On Thu, 10 May 2012, Mischa Salle wrote:
> >
> >> The real problem emerges if you use both curl+openssl *and* openssl
> >> directly, then you can just hope that the cleanup functions put the pointers
> >> to NULL to prevent double free()'s...
> >
> >
> > I believe this is generally safe with modern OpenSSL versions.
> >
> >
> >> Concerning the init: in principle the curl_global_init is called
> >> automatically by the curl_easy_init if you don't do it explicitly (if I'm
> >> not mistaken).
> >
> >
> > That is correct. But as curl_global_init() isn't thread safe etc, letting
> > your program depend on the "automatic" init might not be the wisest idea.
> >
> >
> > --
> >
> > / daniel.haxx.se
> > -------------------------------------------------------------------
> > List admin: http://cool.haxx.se/list/listinfo/curl-library
> > Etiquette: http://curl.haxx.se/mail/etiquette.html
>
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
-- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle_at_nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
- application/x-pkcs7-signature attachment: smime.p7s