What appears to be happening is that my system (Linux 2.6.17 and 2.6.13) is
setting *only* POLLHUP on poll() when the conditions in my previous mail
occur. As you can see, select.c:Curl_select() does not check for POLLHUP. So
basically what was happening, is poll() was returning immediately (with
POLLHUP set), but when Curl_select() looked at the bits, neither POLLERR or
POLLOUT was set. This still caused Curl_readwrite() to be called, which
quickly returned. Then the transfer() loop kept continuing at full speed
forever.

For whatever reason, an FTP upload in the same conditions set
POLLHUP|POLLERR.

The following patch fixes this problem for me. -Matt

--- select.c.orig 2006-12-04 14:05:39.000000000 -0500
+++ select.c 2006-12-04 14:27:32.000000000 -0500
@@ -124,7 +124,7 @@
   if (writefd != CURL_SOCKET_BAD) {
     if (pfd[num].revents & POLLOUT)
       ret |= CSELECT_OUT;
- if (pfd[num].revents & POLLERR)
+ if (pfd[num].revents & (POLLERR|POLLHUP))
       ret |= CSELECT_ERR;
   }

-----Original Message-----
From: curl-users-bounces_at_cool.haxx.se
[mailto:curl-users-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Thursday, November 30, 2006 9:47 AM
To: the curl tool
Subject: Re: 100% CPU usage when connection closed on HTTP upload

On Thu, 30 Nov 2006, Matt Witherspoon wrote:

> This only seems to happen with HTTP upload (not HTTP download or FTP
> upload/download).

That's very strange, since the actual data-sending is the exact same code
for
FTP as for HTTP...

> 7.16.0 was compiled by myself, 7.13.1 came with FC4. Anyone have any
> suggestions? I will attempt to look into the Curl source, but I thought
I'd
> check on here before going that route in case I'm simply doing something
> wrong :)

I don't think you _can_ do anythign wrong as a user of the tool, it _should_

detect the situation, and at least never just go 100% CPU.

See lib/sendf.c:Curl_write() for the internal function that sends data to
the
server.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html