RE: [squid-users] Squid 2.5 and SmartFilter causing frequent crashes

On Wed, 2003-03-19 at 14:22, Lightfoot.Michael wrote:

Your email is ( I think ) taken as intended....

> > > 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.
> >
> Well can you tell me whether this is a squid code problem or a
> SmartFilter problem?

Not for sure, no. But I really do believe it is a
SmartFilter-patch-to-squid problem.

> And I _know_ this is a different error to the
> non-committal one about a segment violation. I thought they _might_ be
> related.

It's quite likely that they are.

> Neither produces a core file so I can't even get past square
> one.

Ah. Well, if you can trigger the segment violation under gdb you will be
able to enter 'bt' to get a back trace. There is a FAQ entry on creation
of core files (http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.19).
I'm not a solaris guru, I can't be of much help there sight unseen I'm
afraid.

> > > 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.
> >
> And I won't bother you with it, except to note that store_client.c line
> 201 and the surrounding code is not changed by the SmartFilter patches.
> In fact none of the store*.c files are changed by SmartFilter. Perhaps
> this assert is really a squid problem, triggered by something that the
> SmartFilter code does?

Until we get the same assert from a non-smartfilter squid-2.5, I'm
assuming that the assert is triggered by the SmartFilter code. It's
highly likely that something they do is causing this, and it's only the
squid code that is detecting it. store_client is used most heavily by
client_side.c. store_client provides the logic to grab data from
*either* the disk or the upstream server.

To troubleshoot, we really need to know whats in the stack frames
immediately leading into the assert (and likewise for the segment
violation). Running under gdb is a good way to get this if you cannot
get a core file). There is a FAQ entry on how to get gdb to do the right
thing as well.

> > Right. That should give you a clue :}.
> >
> And that isn't a lecture, smiley or not?

I didn't think it was. I was indicating that the 99.9999% probable cause
of the fault is in the proprietary code. I wasn't intending to talk
about the ethics or political issues relating to proprietary patches to
GPL code. I could, if you wanted me to - but that is best for a
different list, at a different time.

> Robert, you gave me a useless answer last time as well. Please don't be
> so arrogant.

This I take some offence to. I wasn't intending arrogance. I am trying
to point you in the right direction.

In terms of a useless reply, my previous one
(http://www.squid-cache.org/mail-archive/squid-users/200302/0016.html)
is much less than useless. It's concise yes, but:
Your version stamp in the previously reported fault was prior to the
aufs bugfix that is on the 2.5 errata page
(http://www.squid-cache.org/Versions/v2/2.5/bugs/).

Telling you to apply the errata was apparently a waste of time, or you
might not have called that reply useless. And in fact, it appears to
have reduced the rate of the segfault you where experiencing, no?

As to telling you to create a core when you said that one was not being
created, you had not specified that you had trouble *getting one*,
rather that one was *not being created*. For all I knew you had your
ulimits were/are too low.

Please, take my advice *before* calling me arrogant. If the advice is
wrong: then yes, call me that, and it may be accurate. Calling me
arrogant when you hadn't followed through on the advice you got is,
well. Silly.

> What I am looking for is some guidance on how I can beat
> Secure Computing about the head. They are being largely unhelpful, you
> are being wholly unhelpful.
> Maybe you could read my message again and
> try to give me an answer to my question: "What can I do to get better
> diagnostics?"

To get better diagnostics you need to:
* get a stack trace. Somehow. Anyhow.

Thats the key initial step.

Alternatively, you could up the debug levels via the debug_options
squid.conf statement, which will be *very* noisy in the log files, but
may give you *some* insight.

I am sympathetic to your plight with Secure Computing. I really am. But
there really is very little I can do: I can't examine your source
without being tainted. I can't refer to my source here to provide
guidance. And without a stack trace, I cannot even *guess* at the root
cause of the fault.

What I can say, I pretty much already have.

I make my living of squid consulting, and it pains me to see you having
such trouble. To offer you better advice, I'd need a NDA with Secure
Computing that explicitly does not prevent me from writing the code I
write for squid - which may (I don't know, obviously :}) overlap
SmartFilter quite a bit. In other words the door is open here, but you
really do need to get the S.C. guys actively assisting.

Heck, with such an NDA in place, if you wanted me too I could provide
commercial support for you, and fix the problem ASAP.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.