Memory Leak detected by Valgrind

[Sileno de Oliveira Brito via curl-library]

How to solve the memory leak question when use the libcurl?
in my main i have in line 33 the call

curl_global_init(CURL_GLOBAL_ALL);

at end of code i have the call:
curl_global_cleanup();

But this not solve the problem, how i can remove all memory leak?

16 still reachable are when i use the libcurl, 1 is another lib.

This is part of my output from valgrind:

==25787== 8 bytes in 1 blocks are still reachable in loss record 1 of 17
==25787== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==25787== by 0x9FA2438: ??? (in
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.6)
==25787== by 0x9FA362B: ??? (in
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.6)
==25787== by 0xA05B8D4: ??? (in
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.6)
==25787== by 0xA05B903: ??? (in
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.6)
==25787== by 0xA05BA19: ??? (in
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.6)
==25787== by 0x9FA238F: ??? (in
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.6)
==25787== by 0x9FA2A78: ??? (in
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.6)
==25787== by 0x9F9F048: gcry_control (in
/lib/x86_64-linux-gnu/libgcrypt.so.20.1.6)
==25787== by 0x7535449: libssh2_init (in
/usr/lib/x86_64-linux-gnu/libssh2.so.1.0.1)
==25787== by 0x572021B: ??? (in
/usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==25787== by 0x110EA1: main (main.cpp:33)


==25787== 24 bytes in 1 blocks are still reachable in loss record 4 of 17
==25787== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==25787== by 0x7C2EC87: CRYPTO_malloc (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7CE6775: lh_insert (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7C30113: ??? (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7C30B0A: ??? (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7CD754A: ENGINE_new (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7CDC0D5: ENGINE_load_dynamic (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7CD9BC2: ENGINE_load_builtin_engines (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x574F4CD: ??? (in
/usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==25787== by 0x5720204: ??? (in
/usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==25787== by 0x110EA1: main (main.cpp:33)


==25787== 32 bytes in 1 blocks are still reachable in loss record 12 of 17
==25787== at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==25787== by 0x7C2EC87: CRYPTO_malloc (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7CE5C3C: sk_new (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7C300F7: ??? (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7C30B0A: ??? (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7CDC943: BIO_set (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7CDC9C1: BIO_new (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7CDE8F3: BIO_new_file (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7D3E8F8: ??? (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x7D3F234: CONF_modules_load_file (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2)
==25787== by 0x574F4DB: ??? (in
/usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==25787== by 0x5720204: ??? (in
/usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)

==25787== LEAK SUMMARY:
==25787== definitely lost: 0 bytes in 0 blocks
==25787== indirectly lost: 0 bytes in 0 blocks
==25787== possibly lost: 0 bytes in 0 blocks
==25787== still reachable: 760 bytes in 23 blocks
==25787== suppressed: 0 bytes in 0 blocks

[David Chapman via curl-library]

This post might be inappropriate. Click to display it.

[Michael König via curl-library]

Post by Sileno de Oliveira Brito via curl-library
How to solve the memory leak question when use the libcurl?
in my main i have in line 33 the call

OpenSSL is one of the culprits, which does not do proper cleanup at the programs end. Their attitude has been, that they run until the very end of the programs life, why free everything if the whole heap is disposed of anyway?

While this is true for the purpose of the program itself, it screws over everyone who uses a library like that and intends to use a tool like valgrind or VLD or something like that.

We ran into this issue 10 years ago and i went and looked if there was something i could do to get OpenSSL to do a cleaner, if not absolutely pristine, cleanup.

This is what i came up with:

#include <openssl/conf.h>
#include <openssl/engine.h>
#include <openssl/crypto.h>
#include <openssl/ssl.h>
#include <openssl/err.h>

/* -----------------------------------------------------------------------------------------------------------------------------
* @Function: CleanupSSLLibrary
* @Info : Does all known cleanup for the OpenSSL library to get its memory freed. OpenSSL itself doesnt seem to have any
* severe memory leaks, but it doesnt seem to have any global shutdown routine that frees all reserved memory either.
* So we try our best here to free as much as possible. Once the program is terminated it doesnt matter anyway. The
* output of automated leak detection utilities however will report unfreed memory blocks because of this.
* ----------------------------------------------------------------------------------------------------------------------------- */
void CleanupSSLLibrary(void)
{
int i, iNumOfLocks = CRYPTO_num_locks();

if (l_pLockHandlesSSL != NULL){
CRYPTO_set_locking_callback(NULL);

for (i=0; i < iNumOfLocks; i++) CloseHandle(l_pLockHandlesSSL[i]);

OPENSSL_free(l_pLockHandlesSSL);
l_pLockHandlesSSL = NULL;
}

ENGINE_cleanup();
CONF_modules_unload(1);

/* global application exit cleanup (after all SSL activity is shutdown) */
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();
}

The includes may not be in the necessary order. This is Windows code, you will need another include for "Closehandle" or an equivalent method.

The 1st part deals with freeing the multithreading locks you need for crashless multithreaded operation with OpenSSL. If you did not allocate them you do not need clean them up. Also if you did not allocate them, do not use OpenSSL in a multithreaded fashion!

The 5 calls below should free all but 2 memory buffers that OpenSSL allocates. IIRC ERR_free_strings() needs to be called in each thread that used the error handling of OpenSSL.

Maybe this helps someone, maybe OpenSSL got its act together in the past decade. I do not think it will hurt presenting this here.

Greetings,
Michael König

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: