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 04:21:14 +0200

is the while in main() basically doing:

while (true) {
  PerformCurlWork();
  Sleep(3000);
}

?

/HH

Den sön 9 apr. 2023 kl 03:34 skrev Tyler Wilson via curl-library <
curl-library_at_lists.haxx.se>:

> Thank you for the feedback so far everyone. It wouldn't surprise me
> if the CRT tools in Visual Studio may be providing false positives.
> I'm kinda on a limb here trying to understand why I'm continuously
> allocating memory though.
>
> At the moment, I modified the code slightly to run in a while loop
> with 3000ms sleeps in between each post. When I started the program,
> I was around 3MB but now I'm up to close to 20MB with no signs of
> letting down. And this has been going on for five six hours now. As
> to the question about which line it's coming from, the CRT tools don't
> seem to provide me with that much detail. The only reason I know it's
> the callback is because the bytes match up exactly with the response
> I'm getting from Mockbin.
>
> Is there anyone in the community that deploys this in Windows
> environments in addition to Linux? I realize that most of the samples
> I've seen here are Linux based. I've tried debug mode, release mode,
> etc.. I'm at a complete loss here as to why this isn't working. If
> it helps at all from the Visual Studio side of things:
> Windows SDK Version = 10.0 (latest installed).
> Platform Toolset = Visual Studio 2022 (v143)
> C++ Language Standard = Default ISO C++ 14 Standard
> C Language Standard - Default (Legacy MSVC)
>
> I am going to try and recompile this and switch from Legacy MSVC to
> either C11 or C17 and see if that makes a difference - those are the
> two options I see in Visual Studio. I'll admit I'm more C++ than C,
> but is there a preference to the version of the C standard that my
> program should be compiled with?
>
> Thanks,
> Tyler
>
> On Sat, Apr 8, 2023 at 6:25 PM Henrik Holst
> <henrik.holst_at_millistream.com> wrote:
> >
> > 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:
> >>>
> >>> 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
>

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

Received on 2023-04-09