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:

  ERR_remove_state(0);
  CONF_modules_free();

  ENGINE_cleanup();
  CONF_modules_unload(1);

  ERR_free_strings();
  EVP_cleanup();
  CRYPTO_cleanup_all_ex_data();

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
too.

Thanks,
Huzaifa

On Mon, Dec 22, 2008 at 12:48 PM, Dan Fandrich <dan_at_coneharvesters.com> 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/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)
>
> LEAK SUMMARY:
> 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
> --
> http://www.MoveAnnouncer.com The web change of address service
> Let webmasters know that your web site has moved
>
Received on 2008-12-22