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: Tue, 14 Jun 2011 12:00:50 +0200

Bugs item #3316172, was opened at 2011-06-14 11:38
Message generated for change (Comment added) 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: Open
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-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-14

These mail archives are generated by hypermail.

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

File upload with ASP.NET