dykiel> Hello, the simple piece of code below results in "4243 bytes leaked in 280 
chunks" as reported by the CRYPTO debug memory functions.
dykiel> 
dykiel> Most leaks are caused by the call to SSLeay_add_all_algorithms.

No surprise there.  That function, and the functions called by it,
register a number of algorithms by creating a hash table where the
information needed is stored.

dykiel> Some leaks are caused by the calls to the CRYPTO debug memory
dykiel> functions, but I can  live with that.

Equally unsurprising.  That one will also create a hash table to
store the allocation information in, and sometimes another small hash
table to store some thread-specific information in.

dykiel> Am I missing some mandatory cleanup call? Anyone has tested
dykiel> for mem leaks on other platforms? Any advice, experience?

Those you've fuond aren't a big concern on most common systems,
especially since those are one-time calls.  When a program exits, it's
memory space is usually cleaned out by the operating system.  However,
I imagine that some systems (was it Lennart Bång who was playing with
something like that?) do not work like that, and there might be a
possibility for problems...

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-708-26 53 44
Procurator Odiosus Ex Infernis             -- [EMAIL PROTECTED]
           Member of the OpenSSL development team

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to