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.
 *
 * This is fixed replace for curl_easy_cleanup(). The
curl_easy_cleanup() contains incorrect
 * code for multithread usage of libcurl with OpenSSL.
 * It does not contains code for local thread ERR table cleaning.
 */
void curl_easy_cleanup_multithreads(CURL *curl)
{
        curl_easy_cleanup(curl);

        /* If SSLeay exists */
        #if defined(USE_SSLEAY)
                /* Free thread local error state, destroying hash upon zero refcount */
                #ifdef HAVE_ERR_REMOVE_THREAD_STATE
                        ERR_remove_thread_state(NULL);
                #else
                        ERR_remove_state(0);
                #endif
        #endif
}

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:

void curl_global_cleanup_multithreads(void)
{
        if(!initialized)
                return;

        if(--initialized)
                return;

        curl_global_cleanup();

        #if defined(USE_SSLEAY)
                CRYPTO_w_lock(CRYPTO_LOCK_SSL);
                sk_SSL_COMP_pop_free( SSL_COMP_get_compression_methods(), CRYPTO_free );
                CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
        #endif
}

With best regards, Kyselgov E.N.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-02-29