On Fri, 1 Aug 2003, John Barker wrote:

> I've been using libCurl with OpenSSL for a little while now in a resident
> service for Windows platforms. Every so often it requires to POST some data
> to a webserver of ours using SSL. I noticed recently that this service was
> growing in size very slowly, after 5 days it had reached a resident size of
> 120mb from 2mb. Memory leaks!

Ough.

> So I went through some debugging, looked at all my code and ran some tests.
> Found some memory leaks, none of them had recorded filenames - thus I was
> certain they weren't in my code. I commented out where I was using libCurl,
> the memory leaks went away. So I turned on libCurl memory debugging, nothing
> found. Then I turned off USE_SSLEAY when compiling libCurl. No memory leaks.

Nice move on the USE_SSLEAY testing.

> At this point I'm wondering, is there a proper way to clean up libCurl to
> ensure that it frees any SSL resources? I'm just using a curl_easy_init()
> and curl_easy_cleanup() at the moment.

curl_easy_cleanup() should of course cleanup most(*) resources libcurl has in
use and if things work correctly it shouldn't leak memory when used this way.

There's also the risk that OpenSSL has a leak in itself that libcurl cannot
affect, even though I'm suspecting an SSL resource left allocated somewhere in
the libcurl code.

libcurl version? OpenSSL version? There was a known memory leak in all libcurl
versions prior to 7.10.3 that we've corrected.

Can you make this leak happen with a small source code example you can post to
the list?

(*) = everything should be completely gone after curl_global_cleanup(), but by
not using this shouldn't cause any leaks anyway.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01