Re: Memory leak with curl_multi_socket_action
Date: Tue, 26 May 2020 16:21:13 +0100
On Tue, May 26, 2020 at 3:43 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Tue, 26 May 2020, James Read via curl-library wrote:
>
> > When parallel connections reaches 0 g->still_running is still reporting
> a
> > number of easy handles in progress. How can this be? Surely, the answer
> to
> > this question is the answer to the memory leaks?
>
> Your code makes funny assumptions about sockets and transfers correlations
> that seem incorrect. They're not mapped 1:1. A single transfer may add
> one,
> two or more sockets to monitor. Multiple transfers may add more or may
> reuse
> the same sockets. You can count socket if you want, but do not presume
> that
> you know how many transfers a certain number of monitored sockets actually
> mean.
>
> If you want to count number of concurrent transfers, count how many easy
> handles you've added to the multi handle and subtract again when you
> remove
> them.
>
>
OK. Thanks for that. New code with suggested fix is now at:
git clone https://github.com/JamesRead5737/libcurlmemoryleak.git
valgrind now reports:
==264850== HEAP SUMMARY:
==264850== in use at exit: 0 bytes in 0 blocks
==264850== total heap usage: 162,288 allocs, 162,288 frees, 1,253,100,438
bytes allocated
==264850==
==264850== All heap blocks were freed -- no leaks are possible
So, I guess that's problem solved. Thanks.
James Read
> --
>
> / daniel.haxx.se | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://www.wolfssl.com/contact/
>
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-05-26