Hi Jonathon,

nice find! Could you give some details on the set of calls you needed?

Mischa

On Fri, May 11, 2012 at 06:13:51AM -0700, JonathonS wrote:
> Hi MIscha,
>
> Thanks for the help. So I found out that the problem was caused by a
> leak in OpenSSL's call to SSL_library_init. Libcurl makes this call
> which initializes OpenSSL. However, when libcurl attempts to cleanup
> OpenSSL (via a series of OpenSSL calls), the memory is not cleaned up.
> After much research, I found out that OpenSSL does not provide a way
> to clean up this memory leak which occurs in the compression methods
> of OpenSSL. As a simple fix, I had to manually cleanup the
> compression methods memory after I call curl_global_cleanup() using a
> sequence of calls. I wouldn't mind submitting my patch to libcurl for
> consideration, but it seems like this is a bug in OpenSSL and not in
> libcurl. Libcurl looks like it is doing everything correctly.
> Anyways, my library is no longer leaking memory :)
>
> To answer your initial below -- yes, each time my library was
> loaded/unloaded, it was a new 36B that was lost. When running my
> sample app that continuously loaded/unloaded my library, the leak
> became really really big.
>
> Thanks,
> J
>
>
> On Fri, May 11, 2012 at 12:16 AM, Mischa Salle <msalle_at_nikhef.nl> wrote:
> > 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

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