cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [PATCH] segfault when cancelling pipelined requests

From: Dmitry Kurochkin <dmitry.kurochkin_at_gmail.com>
Date: Wed, 23 Jan 2008 15:04:46 +0300

2008/1/23, Daniel Stenberg <daniel_at_haxx.se>:
> On Tue, 22 Jan 2008, Dmitry Kurochkin wrote:
>
> >> Great, now I get it and all is fine. Do you think you could just add a
> >> comment to the source code where that is done that basically describes
> >> this?
> >
> > Attached.
>
> Thanks. However it doesn't seem to be the complete fix for the problems
> related to test case 530. If I run all the tests now, I get failures on 530 at
> times (which doesn't seem to happen if I just run test 530 alone) and if I run
> 530 with a debugger I get really strange output that seems to indicate a
> problem (see below). It looks like the pipe somehow gets stuck? It seems to be
> 100% repeatable for me...

Yep, I am aware of this issue.

Actually, working on this problem I found segfault when canceling
pipelined request. And these are two separate issues.

Tests goes to infinite loop because of poor handling of pipelined
requests by sws. Here is what happens:

1. GET request from client
2. another GET from client immediately follows
3. sws handles this like a single request and returns a single response

Client is stuck waiting for the second response.

So this is not a problem with libcurl but with test http server. I
hope to get to this today and send you a fix.

Regards,
  Dmitry

>
> $ ./runtests.pl -g 530
> [...]
> (gdb) run
> > GET /path/5300003 HTTP/1.1
> Host: 127.0.0.1:8990
> Accept: */*
>
> * STATE: DO => DO_DONE handle 0x80e68f4; (connection #0)
> * Conn 0 send pipe 2 inuse 0 athead 0
> * STATE: DO_DONE => WAITPERFORM handle 0x80e68f4; (connection #0)
> * Conn 0 send pipe 1 inuse 0 athead 1
> * STATE: WAITDO => DO handle 0x80f82a4; (connection #0)
> * Conn 0 recv pipe 2 inuse 1 athead 0
> > GET /path/5300004 HTTP/1.1
> Host: 127.0.0.1:8990
> Accept: */*
>
> * STATE: DO => DO_DONE handle 0x80f82a4; (connection #0)
> * Conn 0 recv pipe 2 inuse 1 athead 0
> * STATE: DO_DONE => WAITPERFORM handle 0x80f82a4; (connection #0)
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * HTTP 1.1 or later with persistent connection, pipelining supported
> < HTTP/1.1 200 OK
> HTTP/1.1 200 OK
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> < Date: Thu, 09 Nov 2010 14:49:00 GMT
> Date: Thu, 09 Nov 2010 14:49:00 GMT
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> * Conn 0 recv pipe 3 inuse 1 athead 0
> [New Thread 0xb78fdab0 (LWP 13343)]
>
> Program received signal SIGINT, Interrupt.
> [Switching to Thread 0xb78fdab0 (LWP 13343)]
> 0xffffe410 in __kernel_vsyscall ()
> (gdb) bt
> #0 0xffffe410 in __kernel_vsyscall ()
> #1 0xb7b6a2ed in select () from /lib/i686/cmov/libc.so.6
> #2 0x0804d2e5 in select_test (num_fds=7, rd=0xbfe311a4, wr=0xbfe31124,
> exc=0xbfe310a4, tv=0xbfe31224) at first.c:34
> #3 0x0804d186 in test (URL=0xbfe31804 "http://127.0.0.1:8990/path/530")
> at lib530.c:148
> #4 0x0804d423 in main (argc=2, argv=0xbfe31474) at first.c:85
>
>
> --
> Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
>
Received on 2008-01-23