Ramsay, Ron wrote:
>
> When you speak of breaking existing applications, I guess you mean
> applications based on the s_server code (or those that use sockets). As
> someone who has written code based on BIOs and not sockets, I am somewhat
> concerned that BIO reference counts are broken. Apparently I cannot make my
> code robust!
>
> We're still not at release 1.0. Please, can something be done?
>
Well the problem is this it doesn't just apply to BIOs and SSL it
applies to lots of other things as well.
There are two types of function that obtain and set one structure in
another. There is the XXX_get_YYY() and XXX_set_YYY().
The problem in this case is with the XXX_set_YYY(). Some of these up the
reference count of the passed object and some do not. The general logic
is that those that do are the ones where it makes sense to use the
passed object later and those that do not are where the object is
effectively "taken over". It could be argued that once you've set a BIO
to be used for SSL you aren't going to do anything with it later.
Unfortunately the logic isn't consistent and isn't documented on a
function by function basis.
Anyway the problem for existing code is this. If you have a function
that "takes over" an object then you'll have something like this:
x = X_new();
XXX_set_YYY(y);
... do something with x ...
X_free(x);
Whereas a reference count function will do this:
x = X_new();
XXX_set_YYY(y);
Y_free(y);
... do something with x ...
X_free(x);
If you change the logic then any code using a "take over" function will
need to be converted or it will have a memory leak. For a long running
mutlithreaded SSL server if this is not done it will grow until it eats
all available memory.
A "take over" function can't use the "reference count" version because
it will end up using freed memory and crash...
I think the best long term solution is to include a log of various "top
level" functions that keeps account of which function allocates what in
which thread. Then a thread can call thread_cleanup() or whatever and
automatically have its unfreed memory released or at least have it log
things in a more readable way. That way the logic can be changed and the
cleanup function can handle the mess.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
