On Mon, 28 May 2001, T. Bharath wrote:

(The docs for OpenSSL really is in a sorry state, which leads to problems
like these...)

> Regarding use of SSL in libCurl i find that SSL_load_error_strings(); and
> SSLeay_add_ssl_algorithms(); are called in Curl_SSLConnect().(i use a
> older version 7.4 so i found them in UrgSSLConnect)

It is named Curl_SSLConnect() in recent versions. The functionality hasn't
changed much though.

> These two functions are to be called once in a process Now consider a
> scenario involving multiple threads, where Curl_SSLConnect() gets called
> in multiple threads these functions are invoked many times.

Indeed...

> I am really not sure the implications of invoking the functions mutiple
> times but one thing is we dont call the clean up functions causing
> leakage(i couldnt find them in the current version either)

Agreed. If nothing else, it'll at least cause memory leaks.

But libcurl can't know if it'll be used for multiple threads or not, why it
has to init those things once for every curl_easy_init() call. An alternative
would be some kind of option to tell libcurl to not do these initialisations
and instead have you (the application) do the "only one init" call... ?

Anyway, I'll make two new functions for "global" SSL inits and cleanups.

> ERR_remove_state(0); (this is thread specific and has to be called in
> every thread that uses the ssl lib)

So SSL_free() doesn't take care of that?

> EVP_cleanup();

What's that doing?

> ERR_free_strings();

I'll make that a "global" free.

> I am using a older version of the libCurl so i tried placing them in
> urlfree() (iam not sure where you place them inthe recent version)

The whole concept of which things that get freed where was changed quite a
lot since the introduced of persistent connections in libcurl 7.7...

> but this was leading to a crash when multiple threads were involved since
> EVP_cleanup();

> ERR_free_strings(); should be called only on application cleanup.

> So the best option was to remove SSL_load_error_strings(); and
> SSLeay_add_ssl_algorithms(); from Curl_SSLConnect() and put them in a
> global function that gets called only once at application startup and put
> the clean up routines EVP_cleanup(); ERR_free_strings(); in another
> global function that has to be called on application exit. and retain
> ERR_remove_state(0) in urlfree() since this is needed for thread clean up

This sounds like a good idea, but also quite "big" changes. I think I'll
introduce this concept:

Two functions for the "global" scope, only to be done once per application,
unregarding on how many threads or uses of libcurl there is gonna be:

 curl_global_init()
 curl_global_cleanup()

... then, to make older applications still run fine, I'll have a check in
curl_easy_init() that if curl_global_init() hasn't been run, invokes it.
It'll make that older applications will continue to leak memory due to not
calling curl_global_cleanup()... but I can't see how I could solve this.
Anyone?

> I cannot send a diff since i am not using the latest version

Ah, but you _should_ use a later version! ;-)

Thanks a lot for this feedback.

-- 
     Daniel Stenberg -- curl dude -- http://curl.haxx.se/
_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library