Bugs item #1229810, was opened at 2005-06-29 18:18
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1229810&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 7
Submitted By: jgarvia (jgarvia)
Assigned to: Daniel Stenberg (bagder)
Summary: Memory leak in curl_easy_perform method

Initial Comment:
Hi all,

I am currently using the libcurl library to perform file
transmissions via FTP.

I have found memory leaks while using the
curl_easy_perform method.

I attach the report summary generated by Insure tool.
I could not generate the 'memdump' file because the
Makefile does not work on my Tru64 UNIX machine
(./configure --enable-debug), but I guess that Insure
report is really complete for this purpose.

On the other hand, I indicate the libcurl version (curl -V) I
am using (I know, it is not the latest one):

************************ curl -V ********************************
curl 7.13.0 (alphaev68-dec-osf5.1a) libcurl/7.13.0
zlib/1.0.8
Protocols: ftp gopher telnet dict ldap http file
Features: IPv6 Largefile libz
******************************************************************

Could anybody tell me if this bug is fixed in the latest
library? (Or if it is a new bug that should be fixed)

Thanks in advance for all your support.

Julio Garvía

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2005-06-30 16:15

Message:
Logged In: YES
user_id=1110

built just now:

$ ./src/curl -V
curl 7.14.1-CVS (alphaev67-dec-osf5.1) libcurl/7.14.1-CVS
Protocols: ftp gopher telnet dict ldap http file
Features: Debug IPv6 Largefile

This is curl on tru64, with --enable-debug (I've just made
it possible).

It shows _no_ leak at all. When getting a file over FTP, I
see two calls to getaddrinfo() and I see two calls to
freeaddrinfo().

I guess now is the time where you show me exactly what you
do to see this leak! ;-)

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-06-30 15:06

Message:
Logged In: YES
user_id=1110

libcurl features a DNS cache where all successful name
resolves are kept, so they are not freed immediately after use.

The call to Curl_cache_addr() adds the resolved data to the
cache.

If the entry remains in the cache until the handle is
closed, it gets freed from Curl_close() when
Curl_hash_destroy() is called.

----------------------------------------------------------------------

Comment By: jgarvia (jgarvia)
Date: 2005-06-30 14:52

Message:
Logged In: YES
user_id=1304874

Yes, I call 'curl_easy_cleanup()' as well as
'curl_global_cleanup()'.

Well, let me show where I guess there is a memory leak
(according to insure report).
As you could see in the source code:
In hostip6.c (line 257) the getaddrinfo function allocates
memory for its fourth parameter and it is returned.
In hostip.c (line 423) the previously returned value is used
(and stored in a local variable - 'addr'), but only released
when 'dns' variable is NULL. Then my question is, Why the
'addr' relasing depends on another variable? I guess the
releasing should be performed as below:
        if(addr) {
            Curl_freeaddrinfo(addr);
        }
The memory leak seems to be provoked because 'addr' is not
always released, due to its releasing depends on another
variable different from 'addr'.

Ciao,

Julio Garvía

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-06-30 13:53

Message:
Logged In: YES
user_id=1110

Did you really call curl_easy_cleanup() too?

----------------------------------------------------------------------

Comment By: jgarvia (jgarvia)
Date: 2005-06-30 11:52

Message:
Logged In: YES
user_id=1304874

I have just installed the new library version and the same
memory leaks are still there.

Regarding the Insure report, I attach the new one.
The way to analyze it, is from down to top (for every
reported chunk).
BTW, the first line of every reported chunk indicates the
function, file and line in which the memory is allocated
(the rest of the lines indicate the points that calls or use
the memory allocated by that first function).

So, analyzing the second reported chunk (in the latest
Insure report) if you go to file 'hostip6.c', function
'Curl_getaddrinfo()' and line '257' you could see how the
leaked memory is allocated (but never released in file
'ftp.c', function 'Curl_perform()' and line '2146').
(This particular leak is about the fourth parameter of
'getaddrinfo' function that is returned by
'Curl_getaddrinfo()', but never released)

Please, if you still need an example, tell me and I will
prepare it for you.

Thanks.

Julio Garvía

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-06-29 19:46

Message:
Logged In: YES
user_id=1110

First, I must admit I don't understand the report. What
source/line does it say allocated the memory that was
leaked? How much memory was it?

Can't you simply build 7.14.0 and test to see if the leak is
still present or not?

Can you show us an example program (that leaks this memory)
that we can use to repeat this problem?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1229810&group_id=976
_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-tracker
Received on 2005-06-30