How to cleanup definitely a curl handle?

user_4861798 0
Viewed 2368

I have the following sample source code which allow to send a HTTP request with libcurl.

I noticed massive memory usage. debug with valgrind show memory leak. Even that I used curl_easy_cleanup(). I used also curl_easy_reset(), curl_global_cleanup() but they don't have any effect at all and the memory leak persist.

I need to know how to free allocated memory by libcurl.

Here after a basic simple source code that initiate and clean libcurl. 

int main()
{
    CURL* pEasy = NULL;  

    pEasy = curl_easy_init();

    if (pEasy != NULL)
    {
        curl_easy_setopt(pEasy, CURLOPT_USERNAME, "test");
        curl_easy_setopt(pEasy, CURLOPT_PASSWORD, "test");
        curl_easy_setopt(pEasy, CURLOPT_URL, "http:/192.168.22.217:3000");

        curl_easy_perform(pEasy);

        curl_easy_cleanup(pEasy);
    }
 }

Valgrind show memory leak of this program.

Find below the valgrind output

 sudo valgrind --leak-check=full --show-leak-kinds=all ./mem
==7215== Memcheck, a memory error detector
==7215== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==7215== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==7215== Command: ./mem
==7215== 



==7215== 
==7215== HEAP SUMMARY:
==7215==     in use at exit: 6,957 bytes in 67 blocks
==7215==   total heap usage: 1,445 allocs, 1,378 frees, 199,287 bytes allocated
==7215== 
==7215== 3 bytes in 1 blocks are still reachable in loss record 1 of 60
==7215==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7215==    by 0x5136489: strdup (strdup.c:42)
==7215==    by 0x5E65B14: PR_NewLogModule (in /usr/lib/x86_64-linux-gnu/libnspr4.so)
==7215==    by 0x5E707A9: ??? (in /usr/lib/x86_64-linux-gnu/libnspr4.so)
==7215==    by 0x4E8FB38: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x4E67344: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x4E674F7: curl_easy_init (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x400872: main (in /home/mem_test/mem)
==7215== 
==7215== 3 bytes in 1 blocks are still reachable in loss record 2 of 60
==7215==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7215==    by 0x5136489: strdup (strdup.c:42)
==7215==    by 0x5E65B14: PR_NewLogModule (in /usr/lib/x86_64-linux-gnu/libnspr4.so)
==7215==    by 0x5E7081B: ??? (in /usr/lib/x86_64-linux-gnu/libnspr4.so)
==7215==    by 0x4E8FB38: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x4E67344: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x4E674F7: curl_easy_init (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x400872: main (in /home/mem_test/mem)
==7215== 
==7215== 4 bytes in 1 blocks are still reachable in loss record 3 of 60
==7215==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7215==    by 0x5136489: strdup (strdup.c:42)
==7215==    by 0x5E65B14: PR_NewLogModule (in /usr/lib/x86_64-linux-gnu/libnspr4.so)
==7215==    by 0x5E707BC: ??? (in /usr/lib/x86_64-linux-gnu/libnspr4.so)
==7215==    by 0x4E8FB38: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x4E67344: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x4E674F7: curl_easy_init (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x400872: main (in /home/mem_test/mem)
==7215== 
......................
==7215== 
==7215== 1,344 bytes in 8 blocks are still reachable in loss record 60 of 60
==7215==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7215==    by 0x5E79749: PR_NewMonitor (in /usr/lib/x86_64-linux-gnu/libnspr4.so)
==7215==    by 0x5E6995D: ??? (in /usr/lib/x86_64-linux-gnu/libnspr4.so)
==7215==    by 0x5E70899: ??? (in /usr/lib/x86_64-linux-gnu/libnspr4.so)
==7215==    by 0x4E8FB38: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x4E67344: ??? (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x4E674F7: curl_easy_init (in /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.4.0)
==7215==    by 0x400872: main (in /home/mem_test/mem)
==7215== 
==7215== LEAK SUMMARY:
==7215==    definitely lost: 0 bytes in 0 blocks
==7215==    indirectly lost: 0 bytes in 0 blocks
==7215==      possibly lost: 0 bytes in 0 blocks
==7215==    still reachable: 6,957 bytes in 67 blocks
==7215==         suppressed: 0 bytes in 0 blocks
==7215== 
==7215== For counts of detected and suppressed errors, rerun with: -v
==7215== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

How to clean properly the curl memories?

memory-leaks libcurl curl c c++
1 Answers

Doing a curl_global_init(0) before curl_easy_init() and doing a curl curl_global_cleanup() after curl_easy_cleanup() seems to fix the issue

==21041== Memcheck, a memory error detector
==21041== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==21041== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==21041== Command: ./a.out
==21041== 
==21041== 
==21041== HEAP SUMMARY:
==21041==     in use at exit: 0 bytes in 0 blocks
==21041==   total heap usage: 1,452 allocs, 1,452 frees, 418,773 bytes allocated
==21041== 
==21041== All heap blocks were freed -- no leaks are possible
==21041== 
==21041== For counts of detected and suppressed errors, rerun with: -v
==21041== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
user_49120370
Related