-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se [mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Max L. Eidswick
Sent: Thursday, August 21, 2008 4:04 PM
To: 'libcurl development'
Subject: RE: known memory leak in simple easy calls in version 17?

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se [mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Thursday, August 21, 2008 9:01 AM
To: libcurl development
Subject: RE: known memory leak in simple easy calls in version 17?

On Thu, 21 Aug 2008, Max L. Eidswick wrote:

> You're probably right, for the simple test case you present, but there have
> been by my count five memory leaks fixed in curl since 7.17.1.
>
> OK, I guess I should transition to 18 -- we are in a release, but if there
> is good reason to believe that there is a leak in 17 we will decide today to
> do a work around (by using a time to kill the service periodically and then
> restart it) or implement version 18.

I don't think its fair to count them as 17 and 18. They're 7.17.x and 7.18.x.
There have been far more releases than 18 since version 7 saw its first
daylight. (If we count beta releases it has been over 200 releases!)

A first approach for your test case could be to stop calling
global_init/cleanup all the time since they're supposed to be called once each
during the process' life time and thus if the leak would be in one of them I
don't think you'll consider it very fatal...

>> Are there any known memory leak issues like this in the version 17 code?

I didn't find any relevant leak in the changelog that we've fixed since 7.17.1

> We have put memory monitoring code in the actual test procs and watched the
> memory increase, but you can just as easily use the Windows Task Manager and
> watch Peak Memory Usage for any test process using the test I posted in a
> loop. It will increase about 50k bytes per 100 iterations.

Well, we do have memory leak detecting code and we run almost 500 test cases
on numerous platforms with memory leak detect tools and we've not found any
leak in this simple case, so clearly something isn't so simple. At least not
in my view...

It would of course be much more intresting to us if you could at least just
try the same stunt with the latest libcurl version to see if this is something
we should care about for real!

-- 
  / daniel.haxx.se
----- ok, it is getting more interesting and less likely it is something in version 17.1 however odd.
1. memory leak happens on test call 
2. drill down into test code and comment out easy perform line, no memory leak
3. write a simple command line test call of exactly the same source, no leak
The case for the memory leak is in the debugger because it is a win32 service, so I run the service proc as though it is in a
process.  The simulation creates only one thread and it loops, so it is not thread mgmt.
That is all I have so far.  As soon as I can insure it is in the libcurl, I will run a test of the latest libcurl.  If I find out
otherwise, I will email.
Max
---------- ok here is the updated info as of Aug 22 2008
The memory leak is in libcurl (very sure)
It takes a lot of iterations to discover it
It happens in secondary Win32 threads (don't forget to close the thread handle)
It is also in 7.18.2, no change that I can see
It is not a consistent number of bytes per iteration
That's about all.
We have to get our release out, so I will try to look into this further in Q4.
Thanks for all the work and support,
Max