On 12/6/2018 5:40 AM, Sileno de Oliveira Brito via curl-library wrote:
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
These are memory blocks that the cryptography libraries chose not to
release. Curl has no control over the libraries. The memory blocks are
statically allocated, so they are not always considered "memory leaks".
Valgrind reports them to be conservative. See for example
https://stackoverflow.com/questions/25737661/valgrind-getting-still-reachable-blocks-with-libssh2
https://stackoverflow.com/questions/3840582/still-reachable-leak-detected-by-valgrind/3857638#3857638
If you don't like seeing the messages about these static allocations,
you can add manual suppression rules to your Valgrind installation:
http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress
--
David Chapman [email protected]
Chapman Consulting -- San Jose, CA
EDA Software Developer, Expert Witness
www.chapman-consulting-sj.com
2018 Chair, IEEE Consultants' Network of Silicon Valley
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
