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

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-05-11