Hi all,

Thanks a lot for the quick response and solution. I have made the change and
it looks good. Thanks once again for making a fantastic piece of software.

Cheers,
Gautam

-----Original Message-----
From: Daniel Stenberg
To: Gautam Mani
Cc: libcurl Mailing list
Sent: 6/10/2002 5:04 AM
Subject: RE: Socket connect error after repeated failures

On Mon, 10 Jun 2002, Gautam Mani wrote:

> Thank you for your response. I am attaching two small section of the
system
> call trace; one is the initial part when the system has still not
reached
> its limit of file descriptors and the other is when it has. If you
notice
> the initial trace (first one), the file descriptor 59 is not closed
(which
> is actually the data socket). Could someone please confirm if this is
> correct, and if there is any fix for this.

I can indeed confirm that it looks like this behavior makes libcurl leak
the
data connection's socket file descriptor...

The 'conn->secondarysocket' is never closed properly on this kind of
error
and when curl_easy_perform() is then called again it is simple assigned
to a
new socket again... (if you'd do curl_easy_cleanup() it would've been
closed
properly though).

Try this patch, and please let us know if it helps:

--- lib/transfer.c 28 May 2002 14:18:36 -0000 1.99
+++ lib/transfer.c 10 Jun 2002 12:03:47 -0000
@@ -1414,6 +1414,13 @@
   if(!res && res2)
     res = res2;

+ if(conn && (-1 !=conn->secondarysocket)) {
+ /* if we failed anywhere, we must clean up the secondary socket if
it
+ was used */
+ sclose(conn->secondarysocket);
+ conn->secondarysocket=-1;
+ }
+
   return res;
 }

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink