Re: [MERGE-3.0] Support large response headers

It is a strange bug. I am able to reproduce it again and again only
while browsing wikipedia site and only if I have set the following debug
info:
  debug_options 26,9 85,9 33,9 87,9 44,9
If I change something in this line the bug disappeared. I can not get
good debug info :-(

Here are some logs and a backtrace:

 2008/04/07 22:34:30.502| clientWriteComplete: FD 31 Keeping Alive
2008/04/07 22:34:30.502| ClientSocketContext::keepaliveNextRequest: FD 31
2008/04/07 22:34:30.502| clientStreamDetach: Detaching node 0x85c5a30
2008/04/07 22:34:30.502| Freeing clientStreamNode 0x85c5a30
2008/04/07 22:34:30.502| httpRequestFree:
http://en.wikipedia.org/images/wikimedia-button.png
2008/04/07 22:34:30.502| clientLogRequest:
al.url='http://en.wikipedia.org/images/wikimedia-button.png'
2008/04/07 22:34:30.502| clientLogRequest: http.code='304'
2008/04/07 22:34:30.502| clientStreamAbort: Aborting stream with tail
0x85c59e8
2008/04/07 22:34:30.502| clientStreamDetach: Detaching node 0x85c59e8
2008/04/07 22:34:30.502| clientStreamDetach: Calling 1 with cbdata
0xb77c6174
2008/04/07 22:34:30.502| Freeing clientStreamNode 0x85c59e8
2008/04/07 22:34:30.502| clientParseRequest: FD 31: attempting to parse
2008/04/07 22:34:30.502| ClientSocketContext:: FD 31: calling
conn->readNextRequest()
2008/04/07 22:34:30.502| ConnStateData::readNextRequest: FD 31 reading
next req
2008/04/07 22:34:30.502| The AsyncCall ConnStateData::requestTimeout
constructed, this=0x86305e0 [call13713]
2008/04/07 22:34:30.502| leaving clientWriteComplete(FD 31, data=0xb7ee30c0)
2008/04/07 22:35:10| assertion failed: pconn.cc:89: "index >= 0"

Program received signal SIGABRT, Aborted.
0xb7f03410 in ?? ()
(gdb) backtrace
#0 0xb7f03410 in ?? ()
#1 0xbfe9bfbc in ?? ()
#2 0x00000006 in ?? ()
#3 0x00001435 in ?? ()
#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)

From linux proc stats (/proc/net/tcp) I can see that it is a client-side
socket ...
Received on Mon Apr 07 2008 - 13:55:10 MDT