Steffen,

you're right and I did it always like you wrote. I made an static =
initialisation class.
This way I don't get the problems anymore.
If I had done a singleton with reference counting it could be possible =
that someone decrements the count to zero and all things for =
deinitialisation are called and afterwards someone constructs and =
initialises again and gets the error.

So now everything works fine.

Thanks to all for the help.

Frank

> -----Urspr=FCngliche Nachricht-----
> Von: owner-openssl-users@openssl.org=20
> [mailtowner-openssl-users@openssl.org] Im Auftrag von=20
> Steffen DETTMER
> Gesendet: Mittwoch, 2. April 2008 10:47
> An: openssl-users@openssl.org
> Betreff: Re: Problem after removing memory leak
>=20
> * Wockenfu=DF, Frank wrote on Wed, Apr 02, 2008 at 09:07 +0200:
> > Thank you for that hint.
> > I will try to rebuild the class as singleton. This could help, but=20
> > isn't really nice.

>=20
> I think you'd need multiple classes. For things done once a=20
> program life time, a C++ class (singleton) may not be suited,=20
> a simple ordinary init function may be sufficient. However,=20
> such an instance could make sense for instance if used on=20
> stack around main in something like this:
>=20
> int main()
> {
> OpenSSLAllEverything allocation;
> return main_();
> }
>=20
> to ensure that it is released exactly once even in case of=20
> exceptions. Maybe the class assert()s that it is constructed=20
> only once to help application developers to find usage=20
> problems quickly.
>=20
> I think it is essential and required to call RAND_seed once=20
> and only once. Functions like X509_verify_cert may be desired=20
> as X509Certificat::verify().
>=20
> > > Doing it per-object creation is unnecessary and error prone (as=20
> > > maybe the case here). I believe it should be possible to=20

> do it once=20
> > > per program lifetime without changing your C++ class too much.

>=20
> Maybe having a static instance counter, so resources could be=20
> freed if the last instance is destroyed? But to much=20
> automagic handling may not be good; imagine, this would be=20
> linked with a similar class that also has its own instance counter...
>=20
> oki,
>=20
> Steffen
> =20
> About Ingenico Throughout the world businesses rely on=20
> Ingenico for secure and expedient electronic transaction=20
> acceptance. Ingenico products leverage proven technology,=20
> established standards and unparalleled ergonomics to provide=20
> optimal reliability, versatility and usability. This=20
> comprehensive range of products is complemented by a global=20
> array of services and partnerships, enabling businesses in a=20
> number of vertical sectors to accept transactions anywhere=20
> their business takes them.
> www.ingenico.com This message may contain confidential and/or=20
> privileged information. If you are not the addressee or=20
> authorized to receive this for the addressee, you must not=20
> use, copy, disclose or take any action based on this message=20
> or any information herein. If you have received this message=20
> in error, please advise the sender immediately by reply=20
> e-mail and delete this message. Thank you for your cooperation.
> __________________________________________________ ____________________
> 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