Re: Memory leak in libcurl
Date: Mon, 22 Dec 2008 12:48:00 -0800
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/vgpreload_memcheck.so)
by 0x43CEF0B: (within /usr/lib/libcrypto.so.0.9.8)
by 0x43CF5A3: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8)
by 0x442B58D: ENGINE_new (in /usr/lib/libcrypto.so.0.9.8)
by 0x408FF8F: (below main) (in /lib/i686/libc-2.6.1.so)
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.
-- http://www.MoveAnnouncer.com The web change of address service Let webmasters know that your web site has movedReceived on 2008-12-22