cURL / Mailing Lists / curl-library / Single Mail


Re: 答复: Many CLOSE_WAIT when handling lots of URLs

From: Michael Wood <>
Date: Fri, 1 Nov 2013 18:12:28 +0200


Please do not top post.

On 1 November 2013 16:34, Shao, Shuchao <> wrote:

> I set the user number to 1, can still reproduce the issue. So the easier
> way to reproduce it is using one client to request many URLs (each one with
> different DNS name, if use the IP address directly could not reproduce it).

Do you have an example program that demonstrates the problem?

I really don't have experience with using git, could you please give me a
> quick instruction on how to revert the commit c43127414d89ccb9 so I can
> test it?

I think the easiest way would be to checkout the commit just before that
and test it. Then check out that commit and test it and see if the first
commit worked while the second one failed.


$ cd src/curl
$ git checkout c43127414d89ccb9^
$ git clean -xdf # This will wipe out
any local changes in your repository.
[compile and test]
$ git checkout c43127414d89ccb9
$ git clean -xdf
[compile and test]
$ git checkout master

If things had been done correctly, those wrong connections should be
> disconnected after receiving the FIN from the peer server.
> Thanks,
> Simon
> -----邮件原件-----
> 发件人: curl-library [] 代表 Daniel
> Stenberg
> 发送时间: Friday, November 1, 2013 4:32 PM
> 收件人: libcurl development
> 主题: RE: Many CLOSE_WAIT when handling lots of URLs
> On Fri, 1 Nov 2013, Shao, Shuchao wrote:
> > I have tested that 7.28.0 and 7.28.1 work well, and 7.29.0 will occur
> > the issue very soon. So the bug should be introduced from 7.29.0.
> Okay great, then we're down to 260 contenders. 7.29.0 was the first
> release we did after the rather large internal restructure in commit
> c43127414d89ccb9 (the so called "always-multi"). It wouldn't surprise me a
> lot if you'd find that the bug exists after that commit but not before.
> It wouldn't really tell us how to fix the problem though, as reverting
> that isn't really helping. Can you verify if that commit is the one
> introducing the probilem?
> Further, you explained that you see the problem with 5000 connections but
> can you think of an easier way to repeat the problem in a lesser scale and
> in a way that we could repeat perhaps?
> The connections that you see in CLOSE_WAIT wrongly, how were they supposed
> to be disconnected or not if things had been done correctly?
> --
> /

Michael Wood <>

List admin:
Received on 2013-11-01