On Wed, 29 Feb 2012, ëÉÓÅÌØÇÏ× å×ÇÅÎÉÊ wrote:

Thanks for your report and help!

So we've been building curl with SSL since 1998, since even before OpenSSL was
called OpenSSL and we *still* have memory leaks. That has to say something
about the state of the API and its documentation...

> Current version of cURL lib compiled with OpenSSL( + zlib) have some
> memory leaks in multi-thread scenario.
>
> The first mem leak - incorrect OpenSLL cleaning in easy interface (function
> curl_easy_cleanup()). The old versions of cURL (in curl_easy_cleanup()) had
> call of ERR_remove_??? OpenSSL method. For single-theraded app this mem pool
> will be cleaned in curl_global_cleanup(), but multi-thread app have memore
> leaks. I propose such fix for multithreading:

> curl_easy_cleanup_multithreads() is the external interface to
> cleaning/freeing the given * easy handle.

Are you really suggesting a separate cleanup call when the library is used
multi-threaded? We really cannot accept that and it would be far too error
prone. We must make the fix work with the existing API and calling
conventions.

Is there a reason we can't just call ERR_remove_thread_state() or
ERR_remove_state() in the existing function?

> /* If SSLeay exists */
> #if defined(USE_SSLEAY)

... but we don't do OpenSSL calls in any other source code than lib/ssluse.c.
It needs to be done properly.

> Second mem leak. OpenSSL 1.0.0 have mem stack for compression
> algorithms - ssl_comp_methods (file ssl_chip.c), but never free it! We
> can do such cleaning in curl_global_cleanup(), for example:

Are you sure about this? Isn't this rather an OpenSSL bug if that is the case?

Can you provide any further information about this?

> #if defined(USE_SSLEAY)

Similarly, the OpenSSL using code must be moved to the correct place.

-- 
  / daniel.haxx.se

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