Re: Strange assertion failure in 2.6 snapshot...

On Tue, Mar 05, 2002, Joe Cooper wrote:
> Hey folks,
>
> It appears that 2.6 after the commloops merge will not perform a PURGE
> without an assertion failure. I get the following:
>
> 2002/03/05 08:36:30| assertion failed: store_client.c:211:
> "sc->cmp_offset == copy_offset"

Thats definitely from my work.
Interesting .. so you're saying that a PURGE will _reliably_ trigger
this bug?

I've had the bug once since I committed the code (damn timing! :)
and someone else has reported it to squid-dev, but I haven't
been able to reproduce it. If you can do it reliably here, please tell
me (and tell me exactly how you're doing the PURGE) and I'll be
happy to track this down and squish it. :-)

The code goes through this path quite frequently, so I'm not sure why
its deciding all of a sudden to read less of an object.
http->out.offset is only ever incremented, so something is being
replaced here (storeentry/storeclient?)

adrian

> And a backtrace of:
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 1024 (LWP 27216)]
> 0x400db5c1 in __kill () from /lib/libc.so.6
> (gdb) bt
> #0 0x400db5c1 in __kill () from /lib/libc.so.6
> #1 0x4005538e in raise (sig=6) at signals.c:65
> #2 0x400dc9a8 in abort () at ../sysdeps/generic/abort.c:88
> #3 0x08065e15 in xassert ()
> #4 0x0809bf30 in storeClientCopy ()
> #5 0x0805fb83 in clientWriteComplete ()
> #6 0x0806274d in CommWriteStateCallbackAndFree ()
> #7 0x08065249 in comm_select ()
> #8 0x08085b35 in main ()
> #9 0x400c9e5e in __libc_start_main (main=0x8085860 <main>, argc=2,
> ubp_av=0xbffffb54, init=0x8049fb0 <_init>, fini=0x80bc720 <_fini>,
> rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffffb4c)
> at ../sysdeps/generic/libc-start.c:129
>
> (gdb) frame 4
> #4 0x0809bf30 in storeClientCopy ()
> (gdb) print sc->cmp_offset
> Attempt to extract a component of a value that is not a structure pointer.
> (gdb) print sc
> $1 = 0x400830d0
> (gdb) print *sc
> $2 = 0.0084132443630149294931509329313612522
>
> This is a snapshot from immediately after the merge, so maybe Adrian has
> fixed it since then? I'll fetch it and check it out next. I was just
> guessing about what sort of information would be needed for debugging--I
> can do another backtrace and print any other values needed to figure out
> what's happening.
>
> Anyway. This seemed weird enough to get some input from Adrian...
>
> Will give this a go on 2.5 and 2.4, also, but I seem to recall I was
> already running 2.5 for some earlier work in this area with no problems.
> (And I suspect someone would have mentioned it by now, also.)
> --
> Joe Cooper <joe@swelltech.com>
> http://www.swelltech.com
> Web Caching Appliances and Support
>
Received on Tue Mar 05 2002 - 16:40:13 MST