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