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      dcchapman_at_acm.org
     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