cURL / Mailing Lists / curl-library / Single Mail


Re: Filedescriptor leak with curl_multi_socket API (CLOSE_WAIT)

From: Daniel Stenberg <>
Date: Fri, 23 Feb 2007 09:48:41 +0100 (CET)

On Fri, 23 Feb 2007, Pedro Larroy wrote:

> I'm using the curl_multi_socket API (debian's 7.15.5-1) with epoll for a
> university research project

I would recommend that you first upgrade to 7.16.1 since the curl_multi_socket
API is very new and we've made some significant bug fixes for it since 7.15.5.
In fact even since 7.16.1...

> and I have noticed a filedescriptor leakage using it. Perhaps I'm not using
> the api correctly, since it's a little tricky to get it right.

I agree that it is. If you have any ideas or feedback on what to improve in
the API or in the docs for the API, please tell us.

> When I recieve CURL_POLL_REMOVE I got epoll errors because apparently the fd
> was beeing already closed by curl, and thus removed of the epoll socket.

Hm. Yes, libcurl does close the socket by itself before it calls the socket
callback with CURL_POLL_REMOVE. It hasn't really struck me before, but I can
see how this could possibly become a problem if the underlying system like
epoll doesn't like it.

> I currently do nothing with CURL_POLL_REMOVE, but I have noticed that
> connections are left in CLOSE_WAIT state indefinitely. My question is that
> if this is my fault or is there a bug in curl.

It sounds like a libcurl bug then.

Any chance you can provide a small example that repeats the problem?

  Commercial curl and libcurl Technical Support:
Received on 2007-02-23