cURL / Mailing Lists / curl-users / Single Mail


RE: 100% CPU usage when connection closed on HTTP upload

From: Matt Witherspoon <>
Date: Mon, 4 Dec 2006 19:17:20 -0500

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

For whatever reason, an FTP upload in the same conditions set

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-----
[] 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
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
> 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

  Commercial curl and libcurl Technical Support:
Received on 2006-12-05