Re: memory still reachable post calling SSL_CTX_free

2022-06-21 Thread Matt Caswell




On 21/06/2022 11:42, Tomas Mraz wrote:


This is actually not a memory allocated by the SSL_CTX_new() itself but
error string data that is global. There is no real memory leak here.
You can call OPENSSL_cleanup() to explicitly de-allocate all the global
data however please note that you can do it really only before
immediate exit of the application using OpenSSL otherwise you risk
crashes if something tries to call OpenSSL again after
OPENSSL_cleanup() was called.


Better is to not call OPENSSL_cleanup() explicitly at all and just leave 
it. OPENSSL_cleanup() is called automatically at process exit.


Matt



Re: memory still reachable post calling SSL_CTX_free

2022-06-21 Thread Tomas Mraz
On Tue, 2022-06-21 at 10:33 +, Tiwari, Hari Sahaya wrote:
> Hi,
> I need one clarification on routine SSL_CTX_free(). I see the memory
> is not freed even after calling this SSL_CTX_free().
>  
> I have a simple test program, which just does SSL_CTX_new() and 
> SSL_CTX_free().
>  
> #include
> #include 
>  
> int main()
> {
>     const SSL_METHOD *method;
>     SSL_CTX *ctx = NULL;
>     OPENSSL_init_ssl(0, NULL);
>     method = TLS_method();
>     ctx = SSL_CTX_new(method);
>     if ( ctx == NULL ) {
>     return(-1);
>     }
>     SSL_CTX_free(ctx);
>     ctx=NULL;
>     sleep(300);

sleep() won't help you at all as there is no concurrent thread running
or anything else that would remove things for you when the process is
sleeping.

> }
>  
> If the program is terminated after it enters the sleep, I am seeing
> memory is still reachable in valgrind.
>  
> Here is output from valgrind,
>  
> ==443000== 10,224 bytes in 426 blocks are still reachable in loss
> record 593 of 594
> ==443000==    at 0x4C34F0B: malloc (vg_replace_malloc.c:307)
> ==443000==    by 0x525D775: OPENSSL_LH_insert (in
> /usr/lib64/libcrypto.so.1.1.1g)
> ==443000==    by 0x522DDB2: ??? (in /usr/lib64/libcrypto.so.1.1.1g)
> ==443000==    by 0x522E1CF: ERR_load_strings_const (in
> /usr/lib64/libcrypto.so.1.1.1g)
> ==443000==    by 0x4E79083: ERR_load_SSL_strings (in
> /usr/lib64/libssl.so.1.1.1g)
> ==443000==    by 0x4E790BC: ??? (in /usr/lib64/libssl.so.1.1.1g)
> ==443000==    by 0x5DABCD6: __pthread_once_slow (in
> /usr/lib64/libpthread-2.28.so)
> ==443000==    by 0x52C4ADC: CRYPTO_THREAD_run_once (in
> /usr/lib64/libcrypto.so.1.1.1g)
> ==443000==    by 0x4E794FA: OPENSSL_init_ssl (in
> /usr/lib64/libssl.so.1.1.1g)
> ==443000==    by 0x4E7D371: SSL_CTX_new (in
> /usr/lib64/libssl.so.1.1.1g)
> ==443000==    by 0x400749: main (in /home/hari/a.out)
> 

This is actually not a memory allocated by the SSL_CTX_new() itself but
error string data that is global. There is no real memory leak here.
You can call OPENSSL_cleanup() to explicitly de-allocate all the global
data however please note that you can do it really only before
immediate exit of the application using OpenSSL otherwise you risk
crashes if something tries to call OpenSSL again after
OPENSSL_cleanup() was called.

> SSL_CTX_free is already called before sleep(), but memory is still
> hanging around.
> Is there something I am missing here? Do I need to follow some other
> steps ?
> This memory leak is impacting our long term running processes, which
> allocate and free context.

This should not be the case as this memory should be allocated only
once. If you, in your test code, do SSL_CTX_new/SSL_CTX_free in a loop
you should still see just the same memory leaked and not more blocks.

-- 
Tomáš Mráz, OpenSSL



memory still reachable post calling SSL_CTX_free

2022-06-21 Thread Tiwari, Hari Sahaya
Hi,
I need one clarification on routine SSL_CTX_free(). I see the memory is not 
freed even after calling this SSL_CTX_free().

I have a simple test program, which just does SSL_CTX_new() and  SSL_CTX_free().

#include
#include 

int main()
{
const SSL_METHOD *method;
SSL_CTX *ctx = NULL;
OPENSSL_init_ssl(0, NULL);
method = TLS_method();
ctx = SSL_CTX_new(method);
if ( ctx == NULL ) {
return(-1);
}
SSL_CTX_free(ctx);
ctx=NULL;
sleep(300);
}

If the program is terminated after it enters the sleep, I am seeing memory is 
still reachable in valgrind.

Here is output from valgrind,

==443000== 10,224 bytes in 426 blocks are still reachable in loss record 593 of 
594
==443000==at 0x4C34F0B: malloc (vg_replace_malloc.c:307)
==443000==by 0x525D775: OPENSSL_LH_insert (in 
/usr/lib64/libcrypto.so.1.1.1g)
==443000==by 0x522DDB2: ??? (in /usr/lib64/libcrypto.so.1.1.1g)
==443000==by 0x522E1CF: ERR_load_strings_const (in 
/usr/lib64/libcrypto.so.1.1.1g)
==443000==by 0x4E79083: ERR_load_SSL_strings (in 
/usr/lib64/libssl.so.1.1.1g)
==443000==by 0x4E790BC: ??? (in /usr/lib64/libssl.so.1.1.1g)
==443000==by 0x5DABCD6: __pthread_once_slow (in 
/usr/lib64/libpthread-2.28.so)
==443000==by 0x52C4ADC: CRYPTO_THREAD_run_once (in 
/usr/lib64/libcrypto.so.1.1.1g)
==443000==by 0x4E794FA: OPENSSL_init_ssl (in /usr/lib64/libssl.so.1.1.1g)
==443000==by 0x4E7D371: SSL_CTX_new (in /usr/lib64/libssl.so.1.1.1g)
==443000==by 0x400749: main (in /home/hari/a.out)

SSL_CTX_free is already called before sleep(), but memory is still hanging 
around.
Is there something I am missing here? Do I need to follow some other steps ?
This memory leak is impacting our long term running processes, which allocate 
and free context.
Any pointers will be very helpful.

Thanks,
Hari.