Jeremy,
The application still grows intermittently by multiples of 4KB although
the memory leak tools provided by SSL and myself shows no memory leaks.
The start for the checking of the memory leaks is before the SSL_new()
and the actual check is after SSL_free().
It should be noted that on AIX, the process grows quickly initially and
then slows down after many iterations and hours, but I need to verify if it
actually comes to a halt.
On the Solaris platform, the memory size of the process is bigger, but
it stops growing almost immediately (after 2 iterations of 124 sessions
stopped and restarted)
On the AIX platform, it doesn't get that big as quickly, but keeps on
growing slowly after many iterations. The pagesize on Solaris is 8192 bytes
whereas the pagesize on AIX 4096 bytes which may
explain the diff in the memory sizes.
Perhaps, as you say, I should use a more general tool for checking this
stuff.
Thanks,
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
