More on the embedded issue - initialization and dynamic memory.
I now run openssl and the s_server example on my rtos/powerpc
and stumbled into some problems that generated this improvement
suggestion.
I run the s_server multiple times in a shell and for each time
a process is created to run the code. Once finnished,
the program exists and the process is killed. Now here is the
bad part. The global 'static LHASH *thread_hash' variable is
a pointer to a LHASH structure that is created (lh_new) when
the first time ERR_get_state is called. But the rtos I use,
uses process specific memory which is automatically cleaned
(read deallocated) once a process is killed and since the
first time I called ERR_get_state is from one example process
the thread_hash memory is gone once that process exists, ULK :)
To move on, I had an initial process that did:
{
ERR_STATE *glob_err_state;
/* Trick to make the error-state hash table (thread_hash) remain allocated. */
glob_err_state = ERR_get_state();
ERR_remove_state(0);
}
, in order to assure that the thread_hash memory was never freed.
Though automatic, I do not think the allocation of thread_hash
should be done from the first process that uses/generates
an error function/error. Some OS's, like the one I use, has
process specific memory that is automatically cleaned as a
process is killed.
Maybe there are more places/functions that automatically
allocated global data structures like this in the context
of the first user :(
I know backwards compability is precious but if the openssl
group is going to change stuff one day I would like to
propose a change to the above.
Maybe there is time for a ssl_init() and crypto_init() where
all the global memory is allocated (the thread_hash is
never released)?
/Lennart Bang
TCP/IP knudel
[EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
