RE: known memory leak in simple easy calls in version 17?
Date: Sat, 23 Aug 2008 12:43:45 -0600
From: curl-library-bounces_at_cool.haxx.se [mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Max L. Eidswick
Sent: Saturday, August 23, 2008 12:16 PM
To: 'libcurl development'
Subject: RE: known memory leak in simple easy calls in version 17?
From: curl-library-bounces_at_cool.haxx.se [mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Dan Fandrich
Sent: Saturday, August 23, 2008 10:53 AM
Subject: Re: known memory leak in simple easy calls in version 17?
On Sat, Aug 23, 2008 at 09:34:52AM -0600, Max L. Eidswick wrote:
> Yes, I tried it both ways in our testing. It is not the callback -- we disabled the only one in use to eliminate the possibility.
> If I can get caught up today, I will run one more set of tests.
> Using /MT or /MTd, leak occurs in both debug and release versions.
There's more than that involved in thread safe use of libcurl. See
and the man page for curl_global_init()
This is a simple libcurl, non OpenSSL or HTTPS/FTPS test -- it is just a part of our standard release testing where we thought
there was a memory leak in our code. After stripping out almost everything except a nominal libcurl test case (in earlier email
example), it was discovered that the memory leak stopped when the easy perform call was commented out.
The call to global init has been done in all three ways just for testing purposes. The test base is with the call in the main
(thread 0) process init and on exit.
> There's more than that involved in thread safe use of libcurl.
Am I missing anything else? All of these tests are static, no dll's.
--- other info ...
I reran the test with the call in the spawned thread (all init code in process init, not in the libcurl thread). It consumes
roughly a 4k page each 7 thread hits. Move the test libcurl call out of the spawned thread and the leak is plugged. Remove the
call to easy perform in the test thread, the leak is plugged.
Received on 2008-08-23