Hmm.. maybe the comm abort logics is not as fool proof as I thought.
Here did I put that patch for adding cbdata fences to comm.. probably
lost.
But on the other hand this looks like it could be a httpState, but
slightly stomped by someone else.. hmm.. the data there looks
suspiciously much like ascii, what do you get if you try to prin
print (char *)httpState
Regards
Henrik
ons 2003-03-12 klockan 09.23 skrev Adrian Chadd:
> On Wed, Mar 12, 2003, Henrik Nordstrom wrote:
>
> > But why is it that we keep running into automake bugs all the time?
> > The use of automake is supposed to cause less grief, not more..
>
> Heh. Bleeding edge features..
>
> btw, check this out:
>
> (gdb) run -ND
> Starting program: /home/adrian/work/squid/squid-cvs/squid3/src/squid -ND
>
> Program received signal SIGABRT, Aborted.
> 0x281efb58 in kill () from /usr/lib/libc.so.4
> (gdb) bt
> #0 0x281efb58 in kill () from /usr/lib/libc.so.4
> #1 0x2823110a in abort () from /usr/lib/libc.so.4
> #2 0x808579b in xassert (msg=0x8109f6a "fd == httpState->fd", file=0x8109cc7
> "http.cc", line=823)
> at debug.cc:352
> #3 0x809efd3 in httpReadReply (fd=1550,
> buf=0xc1b70ec "HTTP/1.0 200 OK\r\nCache-Control: private,no-cache\r\nPragma:
> no-cache\r\nDate: Wed, 12 Mar 2003 09:15:55 GMT\r\nConnection:
> keep-alive\r\nExpires: Thu, 11 Mar 2004 09:15:36 GMT\r\nX-Xact:
> 080d92e5.2e5142af:7fef7"..., len=1676, flag=COMM_OK, xerrno=0, data=0xc1b70b0) at
> http.cc:823
> #4 0x807e78e in CommReadCallbackData::callCallback (this=0x8aae170) at comm.cc:510
> #5 0x807e8c5 in CommCallbackData::callACallback (this=0x8aae170) at comm.cc:542
> #6 0x807e918 in comm_calliocallback () at comm.cc:570
> #7 0x80b4e0b in main (argc=2, argv=0xbfbff780) at main.cc:943
> #8 0x804a96a in _start ()
> (gdb) frame 3
> #3 0x809efd3 in httpReadReply (fd=1550,
> buf=0xc1b70ec "HTTP/1.0 200 OK\r\nCache-Control: private,no-cache\r\nPragma:
> no-cache\r\nDate: Wed, 12 Mar 2003 09:15:55 GMT\r\nConnection:
> keep-alive\r\nExpires: Thu, 11 Mar 2004 09:15:36 GMT\r\nX-Xact:
> 080d92e5.2e5142af:7fef7"..., len=1676, flag=COMM_OK, xerrno=0, data=0xc1b70b0) at
> http.cc:823
> 823 assert (fd == httpState->fd);
> (gdb) print fd
> $1 = 1550
> (gdb) print httpState->fd
> $2 = 1680881712
> (gdb) print *httpState
> $3 = {entry = 0x65322e35, request = 0x32343135,
> reply_hdr = 0x373a6661 <Error reading address 0x373a6661: Bad address>,
> reply_hdr_size = 929457510,
> reply_hdr_state = 224683108, _peer = 0x532d580a, eof = 1462597234, orig_request =
> 0x203a6469,
> fd = 1680881712, flags = {proxying = 0, keepalive = 1, only_if_cached = 0,
> headers_pushed = 0,
> front_end_https = 2, originpeer = 1}, fwd = 0x3331362e, currentOffset =
> 3472339330015638626,
> do_next_read = 808464432, read_sz = 168636976,
> buf = "HTTP/1.0 200 OK\r\nCache-Control: private,no-cache\r\nPragma:
> no-cache\r\nDate: Wed, 12 Mar 2003 09:15:55 GMT\r\nConnection:
> keep-alive\r\nExpires: Thu, 11 Mar 2004 09:15:36 GMT\r\nX-Xact:
> 080d92e5.2e5142af:7fef7"..., ignoreCacheControl = false, surrogateNoStore = false}
> (gdb)
>
> Thats with me 'stressing' out a ufs cache at 75 req/sec and then, once discovering
> we were lagging being (6500 open fds) I SIGKILL'ed the polygraph processes.
> Bewm.
>
>
>
>
> Adrian
--
Henrik Nordstrom <[EMAIL PROTECTED]>
MARA Systems AB, Sweden
