>> Yes, I can see how this makes sense and would fit into the existing
>> setup.
>>
> What about just doing the necssary things just before or after calling
> curl_easy_cleanup,
> unless I'm wrong this is the only function that a few levels down calls
> SSL_CTX_free,
> thus it is under full control of the application.

The problem runs deeper than I originally thought. What I've noticed with my
application was a memory leak when performing HTTPS communication. It turns
out that there is an issue with closing openssl SSL_CTX objects (presumably
similar problems occur with GTLS). Why? Because due to connection caching a
SSL_CTX may persist beyond the lifetime of the easy handle that originally
created it. Currently only Curl_disconnect will call Curl_ssl_close on the
connection, but it simply doesn't happen when the connection is shared. When
cleaning up the original easy handle the connection is saved and correctly
Curl_ssl_close is skipped. However, later when closing the multi handle,
Curl_ssl_close is again not called, this time because the data pointer is
null. And this is the source of the leak I've noticed. I assume that the
same can happen with other resources that are bound to the connection
(rather than to the easy handle) and are deallocated by Curl_disconnect.

I'm not sure what would be the correct solution to this problem. One would
be to move some of the deallocation code to conn_free, another would be to
set the PROT_CLOSEACTION bit when doing SSL connections, and yet another
would be to associate the SSL_CTX with a share handle (although there are
many reasons why NOT to do it). Currently, I've added the Curl_ssl_close
call to conn_free, as can be seen below.

Relating to my original suggestion, of calling the sslctxfun when the
SSL_CTX is about to be freed, I now understand that this is not really an
option, again due to the connection reuse, and the fact that the easy handle
(that carries the sslctxfun) may not be alive at that time. The proper
solution therefore is pending the decision on the previous issue.

Cheers,
Shmul

Index: url.c
===================================================================
RCS file: /cvsroot/curl/curl/lib/url.c,v
retrieving revision 1.584
diff -u -r1.584 url.c
--- url.c 12 Feb 2007 21:13:51 -0000 1.584
+++ url.c 15 Feb 2007 08:49:49 -0000
@@ -1786,6 +1786,8 @@
   Curl_destroy_thread_data(&conn->async);
 #endif

+ Curl_ssl_close(conn);
+
   Curl_free_ssl_config(&conn->ssl_config);

   free(conn); /* free all the connection oriented data */
Received on 2007-02-15