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