cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Issues with libCurl and OpenSSL

From: Kevin D. Bond <kdb_at_korl.com>
Date: Tue, 5 Aug 2003 08:34:20 -0400

Unfortunately, the Microsoft memory leak detection, in addition to real
memory leaks complains about some memory that was allocated, but not
freed. This latter category is not really a memory leak in the normal
sense, and presents a problem primarily in certain DLL use cases.

If you really want to find out how and why a program is leaking memory
on Windows, you need better tools. I have run libcurl and OpenSSL
through Purify and they don't leak memory in my application, but that
does not mean they don't leak in yours. Unfortunately, I no longer
have access to Purify or I would offer to test your code for you, but
you can download a 14 day trial.

-kevin

On Monday, August 4, 2003, at 09:37 PM, 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.
>>
> Okay seems reasonable, but this is not the main issue.
>
>>>> 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?
>>
>
> These memory leaks are detected as a part of the debug memory
> functions included with Microsoft Visual C++. I modified openssl to
> use these memory debug functions and got this output:
>
> Detected memory leaks!
> Dumping objects ->
> .\crypto\lhash\lhash.c(193) : {3390} normal block at 0x009EC760, 12
> bytes long.
> Data: < > B0 C6 9E 00 00 00 00 00 06 00 00 00
> .\crypto\stack\stack.c(126) : {3389} normal block at 0x009EC720, 16
> bytes long.
> Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> .\crypto\stack\stack.c(124) : {3388} normal block at 0x009EC6E0, 20
> bytes long.
> Data: < > 00 00 00 00 20 C7 9E 00 00 00 00 00 04 00 00
> 00
> .\crypto\ex_data.c(308) : {3387} normal block at 0x009EC6B0, 12 bytes
> long.
> Data: < > 06 00 00 00 E0 C6 9E 00 00 00 00 00
> .\crypto\lhash\lhash.c(193) : {3154} normal block at 0x009E8990, 12
> bytes long.
> Data: < > E0 88 9E 00 00 00 00 00 0A 00 00 00
> .\crypto\stack\stack.c(126) : {3153} normal block at 0x009E8950, 16
> bytes long.
> Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> .\crypto\stack\stack.c(124) : {3152} normal block at 0x009E8910, 20
> bytes long.
> Data: < P > 00 00 00 00 50 89 9E 00 00 00 00 00 04 00 00
> 00
> .\crypto\ex_data.c(308) : {3151} normal block at 0x009E88E0, 12 bytes
> long.
> Data: < > 0A 00 00 00 10 89 9E 00 00 00 00 00
> .\crypto\lhash\lhash.c(193) : {3127} normal block at 0x009E82C0, 12
> bytes long.
> Data: < > 10 82 9E 00 00 00 00 00 03 00 00 00
> .\crypto\stack\stack.c(126) : {3126} normal block at 0x009E8280, 16
> bytes long.
> Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> .\crypto\stack\stack.c(124) : {3125} normal block at 0x009E8240, 20
> bytes long.
> Data: < > 00 00 00 00 80 82 9E 00 00 00 00 00 04 00 00
> 00
> .\crypto\ex_data.c(308) : {3124} normal block at 0x009E8210, 12 bytes
> long.
> Data: < @ > 03 00 00 00 40 82 9E 00 00 00 00 00
> .\crypto\lhash\lhash.c(193) : {3052} normal block at 0x009E7C20, 12
> bytes long.
> Data: <p{ > 70 7B 9E 00 00 00 00 00 00 00 00 00
> .\crypto\stack\stack.c(126) : {3051} normal block at 0x009E7BE0, 16
> bytes long.
> Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> .\crypto\stack\stack.c(124) : {3050} normal block at 0x009E7BA0, 20
> bytes long.
> Data: < { > 00 00 00 00 E0 7B 9E 00 00 00 00 00 04 00 00
> 00
> .\crypto\ex_data.c(308) : {3049} normal block at 0x009E7B70, 12 bytes
> long.
> Data: < { > 00 00 00 00 A0 7B 9E 00 00 00 00 00
> .\crypto\lhash\lhash.c(193) : {3047} normal block at 0x009E7AD0, 12
> bytes long.
> Data: < z > 20 7A 9E 00 00 00 00 00 01 00 00 00
> .\crypto\stack\stack.c(126) : {3046} normal block at 0x009E7A90, 16
> bytes long.
> Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> .\crypto\stack\stack.c(124) : {3045} normal block at 0x009E7A50, 20
> bytes long.
> Data: < z > 00 00 00 00 90 7A 9E 00 00 00 00 00 04 00 00
> 00
> .\crypto\ex_data.c(308) : {3044} normal block at 0x009E7A20, 12 bytes
> long.
> Data: < Pz > 01 00 00 00 50 7A 9E 00 00 00 00 00
> .\crypto\lhash\lhash.c(193) : {3040} normal block at 0x009E7850, 12
> bytes long.
> Data: < w > A0 77 9E 00 90 89 9E 00 02 00 00 00
> .\crypto\stack\stack.c(126) : {3039} normal block at 0x009E7810, 16
> bytes long.
> Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> .\crypto\stack\stack.c(124) : {3038} normal block at 0x009E77D0, 20
> bytes long.
> Data: < x > 00 00 00 00 10 78 9E 00 00 00 00 00 04 00 00
> 00
> .\crypto\ex_data.c(308) : {3037} normal block at 0x009E77A0, 12 bytes
> long.
> Data: < w > 02 00 00 00 D0 77 9E 00 00 00 00 00
> .\crypto\lhash\lhash.c(193) : {3022} normal block at 0x009E7250, 12
> bytes long.
> Data: < q > A0 71 9E 00 00 00 00 00 04 00 00 00
> .\crypto\stack\stack.c(126) : {3021} normal block at 0x009E7210, 16
> bytes long.
> Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> .\crypto\stack\stack.c(124) : {3020} normal block at 0x009E71D0, 20
> bytes long.
> Data: < r > 00 00 00 00 10 72 9E 00 00 00 00 00 04 00 00
> 00
> .\crypto\ex_data.c(308) : {3019} normal block at 0x009E71A0, 12 bytes
> long.
> Data: < q > 04 00 00 00 D0 71 9E 00 00 00 00 00
> .\crypto\ex_data.c(339) : {3009} normal block at 0x009E6BA0, 20 bytes
> long.
> Data: < D L > 00 00 00 00 44 16 4C 00 00 00 00 00 00 00 00
> 00
> .\crypto\lhash\lhash.c(193) : {3008} normal block at 0x009E6A10, 12
> bytes long.
> Data: < h > B0 68 9E 00 00 00 00 00 05 00 00 00
> .\crypto\stack\stack.c(126) : {3007} normal block at 0x009E6920, 16
> bytes long.
> Data: < k > A0 6B 9E 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> .\crypto\stack\stack.c(124) : {3006} normal block at 0x009E68E0, 20
> bytes long.
> Data: < i > 01 00 00 00 20 69 9E 00 00 00 00 00 04 00 00
> 00
> .\crypto\ex_data.c(308) : {3005} normal block at 0x009E68B0, 12 bytes
> long.
> Data: < h > 05 00 00 00 E0 68 9E 00 01 00 00 00
> .\crypto\lhash\lhash.c(121) : {3004} normal block at 0x009E6840, 64
> bytes long.
> Data: < | z Px > 20 7C 9E 00 D0 7A 9E 00 50 78 9E 00 C0 82 9E
> 00
> .\crypto\lhash\lhash.c(119) : {3003} normal block at 0x009E6F90, 96
> bytes long.
> Data: <@h C C > 40 68 9E 00 97 B1 43 00 8D B1 43 00 08 00 00
> 00
> Object dump complete.
>
> Not entirely useful, but better than before.
>
>
>
> -------------------------------------------------------
> 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
>

-------------------------------------------------------
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
Received on 2003-08-05