Just to conclude with this:
My process has stopped growing in memory size after about 5 days
which implies that my problem appeared to be a memory management issue (OS
related) and as soon as the
fragmentation from the frees settled, the memory foot print became stable.
Thanks for everyone's help and suggestions.
Regards,
David
--------------------------------------------------
From: "Jeremy Hunt" <jere...@optimation.com.au>
Sent: Tuesday, January 12, 2010 6:14 PM
To: <danny33...@bellsouth.net>; <openssl-users@openssl.org>
Subject: Re: memory growing when using SSL connections
David wrote:
[safeTgram (safetgram-in) receive status: NOT encrypted, NOT signed.]
After running my app for a couple of iterations for over an hour, I get
the following:
[11:45:42] 10 file=stack.c, line=125, thread=15418, number=20,
address=20077768
...
868 bytes leaked in 24 chunks
However, I get the same info over and over again (same time stamps), no
matter the amount of iterations. I believe this shows that
there is no continuous memory leak in SSL. The 868 bytes reported as a
leak by CRYPTO_mem_leaks_fp() appears to be some initial memory
that has been allocated for the life of the application.
Thanks,
David
David, I am a bit confused by what you say ..
Initially you said the application was growing intermittently in 4KB
multiples. Do you see this behaviour when you add Dr Henson's calls?
If so then where have you added the calls? I presume inside the loop after
SSL_new() and SSL_free(), if all you did previously was remove
CRYPTO_cleanup_all_ex_data().
If both of these statements are correct then either CRYPTO_mem_leaks_fp()
missed the leak or it really isn't in your SSL code. Yet you say that
without the SSL code you get no memory leaks, ... and you get no memory
leaks on the Solaris platform. Looks like you may need a more general
tool. Valgrind 3.3 does work on some versions of AIX on some hardware
(experimentally, apparently), you could try to find a copy of the source,
approach the developers or try to build the latest version on AIX. And
there is purify or insure++.
Some other thoughts that you may have already considered:
How large does the memory leak manifest itself? Are there any broken
connections hanging around that might keep memory until they timeout?
There isn't some AIX kernel tuning parameter that keeps memory that has
been freed reported as allocated until another process needs it is there,
in other words tuning for a delayed memory cleanup algorithm?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
