Date: Mon, 27 Jun 2016 15:42:26 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: Memory leak using multi handle
> Message-ID: <alpine.DEB.2.20.1606271538510.22460_at_tvnag.unkk.fr>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> On Mon, 27 Jun 2016, Dan Donahue wrote:
>
> > several files simultaneously. The only issue I am experiencing is
> > the memory 
> > leak. I have verified there are no leaks in my code.
> And the leak stays at this memory amount or does it grow over time?
>
Yes, the leak most certainly grows over time resulting in a crash. I
presented the simplest case here (1 file) in order to arrive at a
solution sooner. The hope is we fix one leak we fix them all.

>  It seems to imply that it is a multi handle that is never freed. It
> *could* be
> >
That's what I've concluded as well. However, we have verified
curl_multi_cleanup does not return an error code.

>  
> a multi handle that's used privately within libcurl by an easy handle
> (because 
Why would an app's dynamically allocated multi handle be used
"privately" within libcurl? And why would a curl_multi_cleanup of the
handle indicate success when clearly it's not? 

How is an app to know its multi handle is being privately used by libcurl so it can clean it up some other manner? How is a privately used multi handle cleaned up?

> it looks like there's a hash there with three entries that also
> aren't freed).
Could the entries be allocated with each call to curl_multi_perform?
(Assuming it takes 3 calls to complete the transfer)

> Does your program ever run a transfer with the easy interface?
It does not.

>
> If you can, running the code with valgrind will probably give us more
> details 
> of where and how exactly the leaks occur.
In process. Will reply with results. 

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-06-27