On Mon, 4 Aug 2003, John Barker wrote:

> So I poked around and found that curl_easy_cleanup() doesn't cleanup the ssl
> error strings. Amending my code by adding
>
> curl_global_cleanup();
>
> before the line 'return 0;' seemed to solve all the memory leaks.

The suggested use of curl_global_cleanup() is in fact documented and this is
not a surprise to me. It is designed to work like this.

> This didn't seem to match my expectations, these memory leaks wouldn't cause
> my program to grow to the sizes i was seeing.

Right, since those error strings should be loaded only once by this.

> char * szPostField = "This is a test to locate memory leaks in our
> software.";
>
> curl_easy_setopt(curlCurlContext, CURLOPT_POSTFIELDS, szPostField);
> curl_easy_setopt(curlCurlContext, CURLOPT_POSTFIELDSIZE,
> strlen(szPostField));
> curl_easy_setopt(curlCurlContext, CURLOPT_URL, "***https url***");
>
> curl_easy_perform(curlCurlContext);
>
> My server side script got the post data, the program then exits with the
> following debug output:
>
> Detected memory leaks!
> Dumping objects ->
> {3373} normal block at 0x009FC760, 12 bytes long.
> Data: < > B0 C6 9F 00 00 00 00 00 06 00 00 00
> ...
> {2986} normal block at 0x009F6BA0, 96 bytes long.
> Data: <0l C C > 30 6C 9F 00 C7 05 43 00 BD 05 43 00 08 00 00 00
> Object dump complete.
>
> I may require some further analysis to locate these.

How many bytes leak in total? How many blocks leaked?

Does the leak amount differ if you change the postfields string length?

What tool are you using to detect these leaks? Can it be used to somehow track
where the allocations are made?

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