On Wed, Jul 22, 2009 at 11:11:40PM +0200, Daniel Stenberg wrote:
> So can you now see this issue with 7.19.5 or even the current CVS
> version? I'm sorry, but until you've repeated the problem with these I
> won't be bothered to work very hard on it.

We've successfully reproduced the issue on 7.19.5, and at the same time
got output from truss (similar to strace). This sheds a bit more light
on what's happening down at the operating system level:

I've stripped out some of the extraneous syscalls, but it looks like
getting into this state requires a couple of errors.

send(5, " G E T / d e v / f i l".., 177, 0) Err#32 EPIPE
    Received signal #13, SIGPIPE [ignored]
close(5) = 0
so_socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP, 0x00000000, SOV_DEFAULT) = 5
close(5) = 0
so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, 0x00000000, SOV_DEFAULT) = 5
fcntl(5, F_GETFL) = 2
fcntl(5, F_SETFL, FWRITE|FNONBLOCK) = 0
connect(5, 0x08045E2C, 16, SOV_DEFAULT) Err#150 EINPROGRESS
pollsys(0x08045D0C, 1, 0x08045CA4, 0x00000000) = 0
send(5, " G E T / d e v / f i l".., 177, 0) Err#134 ENOTCONN

First the socket, or at least it's write half must get shutdown.
Receipt of a signal indicates that we lost the enitre connection,
however. Then we go to connect, but our poll/select for the connection
times out. We try to send, but get a ENOTCONN. This is presumably what
leads to the call to throw away the connection and start over. Not long
after this we encounter a SIGSEGV. With the debugger attached, we can
see it's the exact same location as before.

It looks now like there are two bugs. First, we access the easy_conn
from a freed connectdata, second we don't seem to be waiting for an in
progress connection to finish and call send(3SOCKET) prematurely.

-j
Received on 2009-07-24