cURL
Haxx ad
libcurl

curl's project page on SourceForge.net

Sponsors:
Haxx

cURL > Mailing List > Monthly Index > Single Mail

curl-tracker Archives

[ curl-Bugs-3297118 ] some sockets hang in CLOSE_WAIT forever?

From: SourceForge.net <noreply_at_sourceforge.net>
Date: Tue, 3 May 2011 16:31:48 -0500

Bugs item #3297118, was opened at 2011-05-03 16:31
Message generated for change (Tracker Item Submitted) made by
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3297118&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: bad behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Charles Kerr ()
Assigned to: Daniel Stenberg (bagder)
Summary: some sockets hang in CLOSE_WAIT forever?

Initial Comment:
I'm one of the developers on Transmission, which uses libcurl. A user is reporting that in some cases -- apparently those involving an http redirect -- that Transmission + libcurl is leaving sockets in CLOSE_WAIT indefinitely. This user is on OS X 10.6.6, which appears to be shipping with libcurl 7.19.7.

I haven't seen this issue myself, but I'm not running OS X. So I don't know if this is (a) an issue with libcurl, or (b) an issue with how Transmission is using libcurl, or (c) a phantom issue.

(b) seems the most likely, since there are more eyes on libcurl than on Transmission... but its use of libcurl is trivially straightforward. Does this look correct:

    multi = curl_multi_init( );
    do
    {
         // add tasks to curl
        curl_multi_add_handle( multi, createEasy( session, web, task ));

        // possibly wait a bit via curl_multi_timeout() + curl_multi_fdset() + select()

        // perform
        do {
            mcode = curl_multi_perform( multi, &unused );
        } while( mcode == CURLM_CALL_MULTI_PERFORM );

        // pump completed tasks from the multi
        while(( msg = curl_multi_info_read( multi, &unused ))) {
            if(( msg->msg == CURLMSG_DONE ) && ( msg->easy_handle != NULL )) {
                CURL * e = msg->easy_handle;
                // (libtransmission-centric steps omitted here)
                curl_multi_remove_handle( multi, e );
                curl_easy_cleanup( e );
            }
        }
    }
    while( tasks_remain || app_is_shutting_down ); // pseudocode

Does this look correct to you?

One option suggested is to try CURLOPT_FORBID_REUSE, but that seems like a blunt tool for this case. If Transmission or libcurl really are leaking sockets, it would be better to find out why than to disable reuse.

Thanks for your time. If you have any questions please ask.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3297118&group_id=976
Received on 2011-05-03

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET