> 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?
no it doesnt.ERR_remove_state(0) is needed to clean up some hash entries and
certain other things stored in the sslcontext

> EVP_cleanup();
>What's that doing?
This is the clean up routine for the
SSLeay_add_ssl_algorithms();

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

Sounds good but yes it will not be backward compatible

Daniel Stenberg wrote:

> 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

_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library
Received on 2001-05-28