On 11/11/2010 04:24 PM, Amos Jeffries wrote:
Over in the dynamic generation code this nasty usage case is implemented
by the http_port contexts and again in the context "storage".
Specifically on the http_port... if you recall the history of bug
http://bugs.squid-cache.org/show_bug.cgi?id=2586 the destructor of
http_port globals are perfectly capable of cleanly erasing the member
contexts. We had to leave the SSL context leaking until they could be
*RefCounted* (with a full 1->N count) because active connections held
raw-pointers to it long after the "owner" port was closed.
I am reading the SSL_CTX_free man page:
"SSL_CTX_free() decrements the reference count of ctx, and removes the
SSL_CTX object pointed to by ctx and frees up the allocated memory if
the the reference count has reached 0. "
Looks that openSSL library already uses RefCounts internally.
We should not have any problem releasing SSL contexts even if still used
by active connections.
Why are we consider it as a problem?
I am trying to find in squid-dev related discussions but I can not found
any.
Using a TidyPointers there, with get() method in httpsAccept() to attach
to SSL* children is exactly identical logic to our previous attempt at
making the http_port destructor cleanup.
hmm, I had forgot this bug.
About SSL_CTX objects (and SSL * ?) we may have to use RefCounts. But it
is not so simple. You can not just use a different type of pointer.
Yes. So as I see it, until this problems is resolved the http_port will
need to stay using a raw-pointer.
The context "storage" containers will need a look to see if they suffer
the same problem or resolve it somehow.
The major problem is that we are not passing RefCount or TidyPointers to
the openSSL library functions. We are passing raw pointers.
If they do not throw that is not a problem. Or if they do throw we much
catch in our caller where the pointer can be treated to special cleanup.
From what I can understand the major problem is that on reconfigure
there are SSL_CTX objects which are used by some SSL objects so the
SSL_CTX objects can not be released.
Yes exactly.
Most possible is that we should write a new object classes which
represents SSL objects and their dependencies on SSL_CTX objects...
Maybe.
Or move to GnuTLS and NSS instead of OpenSSL which has been requested by
several groups of people. Apparently GnuTLS has a nicer API as well,
though I have not looked.
Amos
