On Wed, 2003-03-19 at 11:45, Lightfoot.Michael wrote:
> Quite a while ago (over a month) I reported a problem to this list with
> squid 2.5STABLE1 and Secure Computing's SmartFilter software.
> SmartFilter integrates with squid by patching several source files to
> redirect the URL to itself (rather than using the standard redirector
> interface,) by adding a couple of lines to squid.conf and by adding a
> couple of fields to access.log.
>
> At that stage I was running 2.5STABLE1-20021118, SmartFilter 3.1.1 on
> Solaris 7. I am also running Cameron Simpson's Ad Zapper as a standard
> redirector (12 instances.)
>
> I have been conversing with Secure Computing's technical support ever
> since and after some time they decided that Solaris 7 was "unsupported".
> I have since upgraded the server to Solaris 9 with all the latest
> patches (uname -a reports "SunOS minotaur.comcare.gov.au 5.9
> Generic_112233-04 sun4u sparc SUNW,Ultra-60"), which of course is also
> "unsupported" (they are promising support soon and have started
> "testing".)
>
> This caused the frequency of crashes to increase dramatically for a few
> days while I got around to upgrading squid to 2.5STABLE2-20030318 and
> SmartFilter 3.2.0 yesterday. Ad Zapper is regularly upgraded by an
> automatic download every few days.
>
> I am now getting crashes about once per hour or so this morning. Mostly
> all squid's cache.log tells me is that it had a segment violation, but I
> did get the following a short time back:
>
> 2003/03/19 10:46:18| comm_accept: FD 26: (130) Software caused
> connection abort
> 2003/03/19 10:46:18| httpAccept: FD 26: accept failure: (130) Software
> caused connection abort
> 2003/03/19 10:46:51| assertion failed: store_client.c:201: "sc->callback
> == NULL"
> 2003/03/19 10:47:01| Starting Squid Cache version 2.5.STABLE2-20030318
> for sparc-sun-solaris2.9...
>
> The offending code segment is:
>
> /* copy bytes requested by the client */
> void
> storeClientCopy(store_client * sc,
> StoreEntry * e,
> off_t seen_offset,
> off_t copy_offset,
> size_t size,
> char *buf,
> STCB * callback,
> void *data)
> {
> assert(!EBIT_TEST(e->flags, ENTRY_ABORTED));
> debug(20, 3) ("storeClientCopy: %s, seen %d, want %d, size %d, cb
> %p, cbdata %p\n",
> storeKeyText(e->hash.key),
> (int) seen_offset,
> (int) copy_offset,
> (int) size,
> callback,
> data);
> assert(sc != NULL);
> #if STORE_CLIENT_LIST_DEBUG
> assert(sc == storeClientListSearch(e->mem_obj, data));
> #endif
> assert(sc->callback == NULL);
> assert(sc->entry == e);
> sc->seen_offset = seen_offset;
> sc->callback = callback;
> sc->copy_buf = buf;
> sc->copy_size = size;
> sc->copy_offset = copy_offset;
> storeClientCopy2(e, sc);
> }
>
> Does the above mean anything to anybody? How can I get a better
> indication of where the segment violation is occurring? No segment violation is occuring. A logic violation is occuring and triggering an assert. asserts are used to detect programmer error - where the programmer has either misued an internal API, or hasn't covered some corner case and that resulted in inconsistent internal state. > And please no > lectures about source code hacks by commercial vendors! :-) I won't lecture you, but I also can't support you as I don't know what the code you are running looks like. Nor do I want to know. > I am also running squid 2.5STABLE1 on another server under Solaris 2.6 > without SmartFilter or Ad Zapper. It hasn't missed a beat. Right. That should give you a clue :}. Rob -- GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.
signature.asc
Description: This is a digitally signed message part
