Re: [MERGE-3.0] Support large response headers

mån 2008-04-07 klockan 22:54 +0300 skrev Tsantilas Christos:
> #4 0xb7c67060 in raise () from /lib/libc.so.6
> #5 0xb7c68801 in abort () from /lib/libc.so.6
> #6 0x0808f0a0 in xassert (msg=0x817ec96 "index >= 0",
> file=0x817ec83 "pconn.cc", line=89) at debug.cc:578
> #7 0x080e5c96 in IdleConnList::removeFD (this=0xb7694068, fd=17)
> at pconn.cc:89
> #8 0x080e6075 in IdleConnList::read (fd=17, buf=0xb7694080 "", len=0,
> flag=COMM_OK, xerrno=0, data=0xb7694068) at pconn.cc:162
> #9 0x08125d65 in CommIoCbPtrFun::dial (this=0x865f5b4) at CommCalls.cc:150
> #10 0x08062e73 in AsyncCallQueue::fireNext (this=0x836d2d8)
> at AsyncCallQueue.cc:53
> #11 0x08062f59 in AsyncCallQueue::fire (this=0x836d2d8) at
> AsyncCallQueue.cc:39
> #12 0x08097943 in EventLoop::dispatchCalls (this=0xbfe9c250)
> at EventLoop.cc:154
> #13 0x08097b47 in EventLoop::runOnce (this=0xbfe9c250) at EventLoop.cc:131
> #14 0x08097c0a in EventLoop::run (this=0xbfe9c250) at EventLoop.cc:95
> #15 0x080db042 in main (argc=5, argv=0xbfe9c334) at main.cc:1361
> (gdb)

I suspect the following happens:

0. Idle connection open
1. Server closes connection
2. comm loop sees the FD ready for read and schedules the callback as an
async job
3. Squid initiates next request which pops the FD from the idle queue
4. the scheduled callback gets executed which sees EOF and tries to
remove the fd from the idle queue..

A simple workaround is to make this a soft error instead of a fatal
assert.

A better fix would be to make comm_read_cancel cancel already pending
I/O callbacks..

The above SHOULD be extremely timing dependent, but I guess that there
may still be problems with the comm loop timeout and pending async calls
which would expand that window to about 1 second...

Now this is mostly speculations as I am not very familiar with the async
code in trunk, still kind of stuck at 3.0 level..

Regards
Henrik
Received on Mon Apr 07 2008 - 14:13:46 MDT