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