: Monday, September 17, 2012 11:36 AM
To: Michel
Cc: openssl-users@openssl.org
Subject: Re: Memory issues with ssl handshake
Hi again,
I've changed the code to reuse the SSL contexts but in terms of memory
consumption/release it did not change much - if anything at all. By the way,
is there a w
Hi again,
I've changed the code to reuse the SSL contexts but in terms of memory
consumption/release it did not change much - if anything at all. By the
way, is there a way to "unload" a certificate once it has been loaded
into a SSL context via SSL_CTX_use_certificate() ? I didn't find
anyth
On 12.09.2012 16:58, Thomas Eckert wrote:
> Hi,
>
> Valgrind gives me a *lot* of messages like this
[snip]
> Does anyone have some tips for me ?
Have you seen the FAQ entry regarding valgrind:
http://www.openssl.org/support/faq.html#PROG14 ?
Regards,
Dominik
_
Hi Michel,
Thanks for trying to help, I really appreciate it :-)
"Does your app setup and free a context each time a client is connecting ?"
The context is created only when a client requests a HTTPS connection
and is destroyed together with the SSL session once the connection goes
down. It i
Hi again Thomas,
Do you really need to free your context each time you free your TLS
session ?
I believe it is not needed and at least not usual.
If you need several *DIFFERENT* contexts, implying different TLS
configurations/setup, wich, I think, is not so common,
you can keep them 'alive' du
Hi Thomas,
I don't know if it makes a real difference concerning memory leaks,
but I would have freed the TLS session *BEFORE* freing the context :
SSL_free(ssl);
...
SSL_CTX_free(ssl->ctx);
Does your app setup and free a context each time a client is connecting ?
Le 12/09/2012 16:58, T
lto:owner-openssl-us...@openssl.org] On Behalf Of Thomas Eckert
Sent: Wednesday, September 12, 2012 7:59 AM
To: openssl-users@openssl.org
Subject: Memory issues with ssl handshake
Hi,
Valgrind gives me a *lot* of messages like this
==19021== 2,056 bytes in 2 blocks are indirectly lost in loss record 1
Hi,
Valgrind gives me a *lot* of messages like this
==19021== 2,056 bytes in 2 blocks are indirectly lost in loss record 186
of 190
==19021==at 0x68EAC8B: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==19021==by 0x6C472DB: default_malloc_ex (mem.c:79)
==19021==by
