Re: Core details from 2.4.STABLE1+patches

On Wed, Jun 13, 2001, M A Young wrote:

> (gdb) print *mem
> $1 = {method = 1,
> url = 0x1547a1b0
> "http://193.60.176.41/cgi-bin/hugesize.jpg?imtype=q&motion=0&camera=1",
> data_hdr = {head = 0x381a3f0, tail = 0x12620698,
> origin_offset = 2147450880}, inmem_hi = -2147483562,
> inmem_lo = 2147451970, clients = {head = 0x874be0, tail = 0x874be0},
> nclients = 1, swapout = {queue_offset = 0, memnode = 0x0, sio = 0x0},
> reply = 0xc8d3ca8, request = 0x831390, start_ping = {tv_sec = 0,
> tv_usec = 0}, ping_reply_callback = 0, ircb_data = 0x0, fd = 157,
> abort = {
> callback = 0x45b64 <fwdAbort>, data = 0x125dd190},
> log_url = 0x1361c8f0 "http://193.60.176.41/cgi-bin/hugesize.jpg?", repl
> = {
> data = 0x0}, id = 43536639, object_sz = -1, swap_hdr_sz = 0}

This definitely smells of a streaming media connection thats been
left open for a long, long time. The data counters have wrapped,
and this is causing your bug.

Does anyone have any ideas on how this could be prevented in
the current squid code? (yeah, ok, making the counters 64-bit
would work, for now.. :)

Adrian

-- 
Adrian Chadd			<Liedra> Don't worry, I know who *you* are ;)
<adrian@creative.net.au> 	<spiv> We know everything about you.