Re: libcurl 8.0.1 and mem leaks reported on callback - windows x64 build

From: Henrik Holst via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 9 Apr 2023 00:24:55 +0200

btw this could also be due to (and bear with me because it was ages ago
that I did any programming on Windows) you are using one CRT (non debug) of
the curl library and another CRT (debug) of your application so when you
call curl_easy_perform() then Windows switches to the CRT of the libcurl
DLL and then inside that CRT libcurl calls your WriteCallback() function
where it then does a realloc on std::string.

Could be that this switching of CRT:s is what is confusing the memory leak
function of the CRT of your application or (and here I show how little I
know about C++) that readBuffer() is not destroyed when PerformCurlWork()
ends but instead when the libcurl DLL is unloaded which happens after your
call to _CrtDumpMemoryLeaks().

In the page for the function Microsoft writes this:

False positives

_CrtDumpMemoryLeaks can give false indications of memory leaks if a library
marks internal allocations as normal blocks instead of CRT blocks or client
blocks. In that case, _CrtDumpMemoryLeaks is unable to tell the difference
between user allocations and internal library allocations. If the global
destructors for the library allocations run after the point where you call
_CrtDumpMemoryLeaks, every internal library allocation is reported as a
memory leak. Versions of the Standard Template Library earlier than Visual
Studio .NET may cause _CrtDumpMemoryLeaks to report such false positives.

Unsure if any of this applies here due to me not knowing squat about C++
nor Windows anymore.

/HH

Den sön 9 apr. 2023 kl 00:03 skrev Henrik Holst <
henrik.holst_at_millistream.com>:

> sounds like the VS2022 CRT debug tools don't unwind the stack before the
> check so it doesn't call the std:string destructor or something like that.
> I compiled your code on Linux and run it using Valgrind which is the #1
> when it comes to memleak detection and it found none:
>
> henrik_at_Sineya:~$ valgrind ./memleaktest
> ==62452== Memcheck, a memory error detector
> ==62452== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==62452== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright
> info
> ==62452== Command: ./hej
> ==62452==
>
> The response code is: 200
> the curl return code is: 0
> ==62452==
> ==62452== HEAP SUMMARY:
> ==62452== in use at exit: 0 bytes in 0 blocks
> ==62452== total heap usage: 4,633 allocs, 4,633 frees, 444,149 bytes
> allocated
> ==62452==
> ==62452== All heap blocks were freed -- no leaks are possible
> ==62452==
> ==62452== For lists of detected and suppressed errors, rerun with: -s
> ==62452== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> /HH
>
> Den lör 8 apr. 2023 kl 19:11 skrev Tyler Wilson via curl-library <
> curl-library_at_lists.haxx.se>:
>
>> Hi everyone,
>>
>> I'm still learning, but I'm hoping you can help.
>>
>> I have libcurl up and running and love it. But, I'm seeing memory leaks
>> and not sure if it's me or something else.
>>
>> Stats:
>> - Windows platform x64, with Visual Studio 2022.
>> - Downloaded source code from curl website as a .gz file.
>> - Building according to win instructions using Native Tools:
>>
>> 1. *nmake /f Makefile.vc mode=dll MACHINE=x64 WITH_SSL=no DEBUG=no*
>>
>>
>> I have a very simple program that sends data to Mockbin. It responds
>> with the payload I sent plus a whole lot more.
>>
>> When my program is done though, VS2022 CRT debug tools claim that there
>> is a memory leak. Looking at the debug output, it's coming from the
>> response that I'm getting from Mockbin.
>>
>> 'curlmemleakexample.exe' (Win32): Unloaded
>> 'C:\Windows\System32\FWPUCLNT.DLL'
>> Detected memory leaks!
>> Dumping objects ->
>> {160} normal block at 0x000002181100D260, 2496 bytes long.
>> Data: < { > 00 20 20 20 20 20 20 20 20 7B 0A 20 20 20 20 20
>> {159} normal block at 0x00000218110062C0, 16 bytes long.
>> Data: <_at_d > 40 64 80 A5 F6 7F 00 00 00 00 00 00 00 00 00 00
>> Object dump complete.
>>
>> The data above is the response from Mockbin based on the length of the
>> bytes and what I saw come back from Wireshark over HTTP. I am calling
>> global_init before my program starts, and calling global_free when I'm
>> done. I have pasted my sample of code at the following link:
>>
>>
>> https://www.codebin.cc/code/304ead33e4dd78b7bb1eeb36460eed6a9a4fe85506b6f4185329a6e861e00f6e
>>
>> Why would I still be getting reported memory leaks on the information
>> from the callback? Is it because my callback is a global function? Am I
>> maybe not understanding something about the API and maybe it requires the
>> function to do something different?
>>
>> Many thanks in advance for your help and assistance. I hope I was able
>> to give you enough details.
>>
>> Thanks....Tyler!
>> --
>> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>>
>

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2023-04-09