cURL / Mailing Lists / curl-library / Single Mail

curl-library

test 91 fails - cause found?

From: Patrick Smith <patsmith_at_pobox.com>
Date: Sun, 25 Jan 2004 23:30:28 -0500

Test case 91 fails on my Linux system, using curl 7.11.0.

Looking through the archives, I see other people have occasional
failures of this test. For me it almost always fails. A shell loop to
run the test repeatedly succeeded only on the 337'th iteration!

I haven't examined the code and test in enough detail to be sure, but I
believe this is caused by a race condition.

(Some evidence for this being a timing problem: if the curl command is
nice'd, the test always succeeds.)

It seems the way the test is supposed to work is this:
- libcurl opens a connection to the server
- libcurl sends an initial request to the server
- the server replies "Authorization required" and closes the connection
- libcurl opens another connection and sends more requests
- the server replies with data

However, when the test fails, libcurl seems to be re-using the original
connection ("Re-using existing connection! (#0)" appears in thr stderr
log). The server closes this connection without looking for more data,
so libcurl gets an empty reply.

I think the race is between the server's call to close() and libcurl's
call to select() in SocketIsDead in lib/url.c. If the select happens
first, libcurl will reuse the connection, and the test fails.

I'd suggest that this race could occur in real life, whenever libcurl
considers reusing a connection at about the same time as the server
closes the connection. So libcurl should probably try to detect this
case and open a new connection. (I'd guess the things to look for would
be no data from the first recv() or the appropriate error (ECONNRESET?)
from the first send()).

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
Received on 2004-01-28