cURL / Mailing Lists / curl-library / Single Mail


Re: Memory leak in libcurl

From: Huzaifa Al Nahas <>
Date: Mon, 22 Dec 2008 13:41:47 -0800

The memory leak reported by VC++ _CrtDumpMemoryLeaks() is probably
due to the same issue because it only occurs when curl is built with
OPENSSL support. Although the memory leak is not significantly harmful
as it does not grow, I believe that there should be a function that
can be called to free this memory before the application closes. I
tried all the functions suggested in OPENSSL FAQ:




However, the memory leak is still reported. This is probably an
OPENSSL issue, however, I hope that a reader of this mailing list
encountered it and found a solution to it. I reported it to OPENSSL


On Mon, Dec 22, 2008 at 12:48 PM, Dan Fandrich <> wrote:
> On Mon, Dec 22, 2008 at 11:33:57AM -0800, Huzaifa Al Nahas wrote:
>> I used _CrtDumpMemoryLeaks() to check for memory leak. I recently
>> wrote a program that uses libcurl with ssl. Then _CrtDumpMemoryLeaks()
>> reported a memory leak. So I narrowed down the program to find out
>> where this memory leak happens. I found out that just initializing an
>> easy handle and cleaning it will lead to a leak (ie:
>> _CrtDumpMemoryLeaks() reporting a leak). It appears that
>> curl_easy_cleanup function does not clean everything that
>> curl_easy_init function reserves in memory.
> Running valgrind on your program on Linux gives the following:
> ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 43 from 1)
> malloc/free: in use at exit: 276 bytes in 7 blocks.
> malloc/free: 2,009 allocs, 2,002 frees, 68,965 bytes allocated.
> For counts of detected errors, rerun with: -v
> searching for pointers to 7 not-freed blocks.
> checked 262,048 bytes.
> 276 bytes in 7 blocks are still reachable in loss record 1 of 1
> at 0x40204E5: malloc (in /usr/lib/valgrind/x86-linux/
> by 0x43CEF0B: (within /usr/lib/
> by 0x43CF5A3: CRYPTO_malloc (in /usr/lib/
> by 0x442B58D: ENGINE_new (in /usr/lib/
> by 0x408FF8F: (below main) (in /lib/i686/
> definitely lost: 0 bytes in 0 blocks.
> possibly lost: 0 bytes in 0 blocks.
> still reachable: 276 bytes in 7 blocks.
> suppressed: 0 bytes in 0 blocks.
> So it appears that OpenSSL is doing some global library initialization before
> libcurl even gets invoked, and doesn't clean up after itself. If the Windows
> OpenSSL does something similar, then perhaps that's what's being picked up
> by the the memory leak detector you're using.
>>>> Dan
> --
> The web change of address service
> Let webmasters know that your web site has moved
Received on 2008-12-22