Bugs item #3297118, was opened at 2011-05-03 21:31
Message generated for change (Comment added) made by sf-robot
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: Closed
Resolution: Invalid
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.

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

>Comment By: SourceForge Robot (sf-robot)
Date: 2011-05-26 22:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Daniel Stenberg (bagder)
Date: 2011-05-12 21:59

Message:
Thanks for reporting this issue and helping us improve curl and libcurl.

We're awaiting feedback in this issue. Due to this, I have set the state
of this issue to pending and it will automatically get closed later on
unless we get further info.

Please consider answering the outstanding questions or providing the
missing info so that we can proceed to resolve this issue!

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

Comment By: Daniel Stenberg (bagder)
Date: 2011-05-04 17:42

Message:
The CLOSE_WAIT sockets are probably the ones that libcurl has in its
connection cache but that have been "closed" (a FIN was sent) by the server
already but not yet by libcurl.

They are not there "indefinitely" (and they really can't be) since the
connection cache has a limited size so eventually the old connections
should get closed. Also, for each newly created connection when searching
if there's an existing one, libcurl is supposed to detect and close "dead"
connections such as these. Possibly that detection is somehow not working
on Mac OS X.

Your code looks correct and quite frankly, I don't think you describe a
bug but mere symptoms of how libcurl works.

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

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