On 10/12/06, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
>
> Let's not draw quick conclusions. Yes the memory is kept after you've made
> your request, since you can make another one afterwards and it would
> re-use
> that connection and allocated data.

As you will see if you continue to make requests and re-using the same
> handle
> (or even if you don't re-use it), the amount of used memory will go up
> initially when libcurl populates it various caches and buffers but it
> won't
> continue indefinitely and far as I know there is no memory leak in recent
> libcurls.

I think here relies the problem. The memory isn't being reused.
I kept on doing many requests and after a few minutes I shut down my
application. Then I run the perl script. In my new results there is indeed a
memory leak (attached).
(btw, I'm always using the *same* URL for all the requests, so I really
reuse the connections. In my process monitor I indeed see a constant number
of open sockets).

In my debug analysis file I also see messages like:
Mixed debug compile ... rebuild curl now
I rebuilt again both libcurl and my app, and tested again bu the same
message still exist.

I'll try to describe in more details what I do. May be it's something I'm
doing wrong:
1. In my main thread I create a Client object (which holds my easy handle)
when application starts.
2. for each request I need to POST I do as follows:
2a. Set the easy handle using setopt with CURLOPT_HTTPHEADER,
CURLOPT_POSTFIELDS, CURLOPT_POSTFIELDSIZE, CURLOPT_URL, CURLOPT_PORT,
CURLOPT_WRITEDATA, CURLOPT_TIMEOUT
2b. Add the easy handle to my multi
3. My polling thread is doing select/multi_perform/multi_info_read
3. When request is finished (in my polling thread) I post a notification
message to my main thread.
4. In my main thread I remove the easy handle from the multi, so it will be
ready for reuse by the Client if another request is needed.

Because I see many leaks from multi.c (313), I suspect it may be related to
the fact the I'm addid and removing the easy handle from the multi a lot of
times. Maybe this flow was never tested before.

Thanks,
Ori.