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-3316172 ] crash on Curl_expire

From: SourceForge.net <noreply_at_sourceforge.net>
Date: Fri, 17 Jun 2011 14:18:59 +0200

Bugs item #3316172, was opened at 2011-06-14 11:38
Message generated for change (Settings changed) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3316172&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: ftp
Group: crash
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: meteorx (meteorx)
Assigned to: Daniel Stenberg (bagder)
Summary: crash on Curl_expire

Initial Comment:
Platform : gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)
curl version is 7.21.0, compiled it with --enable-debug.

A multi-thread FTP program using libcurl easy interface, it seems hard to reproduce this bug.

(gdb) bt
#0 0x0000000000459d9f in Curl_expire (data=0x1313131313131313, milli=0) at multi.c:2291
#1 0x0000000000474349 in Curl_done (connp=0x2aac47b388, status=CURLE_RECV_ERROR, premature=false) at url.c:5140
#2 0x00000000004840e3 in Curl_do_perform (data=0x1331f008) at transfer.c:2118
#3 0x00000000004841e2 in Curl_perform (data=0x1331f008) at transfer.c:2177
#4 0x0000000000453194 in curl_easy_perform (curl=0x1331f008) at easy.c:567

I guess the connection of SessionHandle has been closed in somewhere before.
And about less than 500ms before this SIGSEGV occured, my CURLOPT_DEBUGFUNCTION callback function got a "Re-used connection seems dead, get a new one". Then I found it in function "Curl_reconnect_request(struct connectdata **connp)" in lib/transfer.c as below:

CURLcode
Curl_reconnect_request(struct connectdata **connp)
{
  CURLcode result = CURLE_OK;
  struct connectdata *conn = *connp;
  struct SessionHandle *data = conn->data;
  
  /* This was a re-use of a connection and we got a write error in the
   * DO-phase. Then we DISCONNECT this connection and have another attempt to
   * CONNECT and then DO again! The retry cannot possibly find another
   * connection to re-use, since we only keep one possible connection for
   * each. */
            
  infof(data, "Re-used connection seems dead, get a new one\n");
    
  conn->bits.close = TRUE; /* enforce close of this connection */
  result = Curl_done(&conn, result, FALSE); /* we are so done with this */

  /* conn may no longer be a good pointer */
    
  /*
   * According to bug report #1330310. We need to check for CURLE_SEND_ERROR
   * here as well. I figure this could happen when the request failed on a FTP
   * connection and thus Curl_done() itself tried to use the connection
   * (again). Slight Lack of feedback in the report, but I don't think this
   * extra check can do much harm.
   */
  if((CURLE_OK == result) || (CURLE_SEND_ERROR == result)) { <<<<<< HERE <<<<<<
    bool async;
    bool protocol_done = TRUE;
  
    /* Now, redo the connect and get a new connection */
    result = Curl_connect(data, connp, &async, &protocol_done);
    if(CURLE_OK == result) {
      /* We have connected or sent away a name resolve query fine */

      conn = *connp; /* setup conn to again point to something nice */
      if(async) {
        /* Now, if async is TRUE here, we need to wait for the name
           to resolve */
        result = Curl_wait_for_resolv(conn, NULL);
        if(result)
          return result;

        /* Resolved, continue with the connection */
        result = Curl_async_resolved(conn, &protocol_done);
        if(result)
          return result;
      }
    }
  }

  return result;
}

So, maybe HERE should check both "CURLE_SEND_ERROR == result" and "CURLE_RECV_ERROR == result" to avoid using a closed connection later ? Not sure about it...

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

Comment By: Daniel Stenberg (bagder)
Date: 2011-06-17 14:18

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-06-14 12:00

Message:
Perhaps, but we've done 6 releases full of bug fixes since your version so
I would still like you to first try out 7.21.6 and see if the problem
remains there.

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

Comment By: meteorx (meteorx)
Date: 2011-06-14 11:58

Message:
CURLcode Curl_done(struct connectdata **connp,
                   CURLcode status, /* an error if this is called after
an
                                        error was detected */
                   bool premature)
{
  CURLcode result;
  struct connectdata *conn;
  struct SessionHandle *data;

  DEBUGASSERT(*connp);

  conn = *connp;
  data = conn->data;

  Curl_expire(data, 0); /* stop timer */

(gdb) up 1
#1 0x0000000000474349 in Curl_done (connp=0x2aac47b388,
status=CURLE_RECV_ERROR, premature=false) at url.c:5140
(gdb) p data
$1 = (struct SessionHandle *) 0x1313131313131313

conn was closed before calling Curl_expire, maybe the problem is not about
expire handling.

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

Comment By: Daniel Stenberg (bagder)
Date: 2011-06-14 11:49

Message:
Please try a more recent libcurl version as we have fixed flaws in the
expire handling since 7.21.0.

I don't think your suggested change is what would be required.

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

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

These mail archives are generated by hypermail.

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

File upload with ASP.NET