Thank you for that hint.
I will try to rebuild the class as singleton. This could help, but isn't =
really nice.

Best regards

Frank

> Wockenfu=DF wrote:
> > Hi all,
> >=20
> > I have written a class in C++ to easily access functions=20

> from OpenSSL from our products.
> > In the constructor of my class I do the following lines of code:
> >=20
> > threadSetup();
> >=20
> > OpenSSL_add_all_digests();
> > OpenSSL_add_all_ciphers();
> > OpenSSL_add_all_algorithms();
> > =09
> > ERR_load_PKCS7_strings();
> > ERR_load_X509_strings();
> > ERR_load_crypto_strings();
> > ERR_load_ERR_strings();
> >=20
> > RAND_seed( rnd_seed, sizeof(rnd_seed) );
> >=20
> > ENGINE_load_builtin_engines();
> >=20
> > In the destructor I do the following:
> >=20
> > ENGINE_cleanup();
> > RAND_cleanup();
> > CRYPTO_cleanup_all_ex_data();
> > ERR_free_strings();
> > threadCleanUp();
> >=20
> > This leads to a memory leak, because of the=20
> > OpenSSL_add_all_...-functions in the constructor. In the=20

> online manual=20
> > I've read that I need to call
> >=20
> > EVP_cleanup();
> >=20
> > in the destructor too. So if I do this all memory leaks are=20

> gone, but=20
> > the function
> >=20
> > X509_verify_cert()
> >=20
> > fails with the error 'certificate signature failure '.
> > If I remove the EVP_cleanup() from the destructor the=20

> function works as fine as it should work.
> >=20
> > Could please anyone give me a hint what could be wrong?
> > The destructor is called at least once before the=20

> constructor is called again and X509_verify_cert is called.
> >=20

>=20
> Ideally these steps should be done once per program=20
> life-time; constructor steps at start-up, destructor steps at=20
> program exit (say in an environment where the OS doesn't=20
> clean up the program's memory).
>=20
> Doing it per-object creation is unnecessary and error prone=20
> (as maybe the case here). I believe it should be possible to=20
> do it once per program lifetime without changing your C++=20
> class too much.
>=20
> -jb
> --
> Real computer scientists don't comment their code. The=20
> identifiers are so long they can't afford the disk space.
> __________________________________________________ ____________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majordomo@openssl.org
>=20

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org