> Something you might try:
> build a unpatched squid-2.5 with a *different* prefix (configure
> --prefix=foo)
>
> give it an used port (say 3140 :}).
>
> ensure your ulimits etc and any solaris requirements for
> getting a core are theoretically correct.
>
> run it with -N.
>
> now, use kill -SIGSEGV <pid of this test squid>
>
> that should cause a core file to be generated. And if it
> doesn't, it will let you experiment without impacting your
> users to find out how to get a core on solaris.
>
Good suggestion. I do have a test squid config on the same box which
currently uses the same squid binary, without SF turned on (there are
two tokens added to squid.conf that enable or disable SF.) Incidetally,
I don't get crashes when I turn the SF config off, even while running
the SF patched code. This does support the theory that it is something
specific in their patches that is causing the two failure symptoms, and
that if the code is not traversed squid behaves perfectly.
Please accept my apologies for the uncalled for accusation of arrogance
yesterday. I guess I'm under a bit of pressure this week, but that's
not a credible excuse is it? :-)
BTW, I did indirectly follow your suggestions in your original message a
month ago - I later turned off aufs and then upgraded squid 2.5S1 to a
more recent snapshot a couple of weeks ago. Neither made any
difference. :-(
Michael Lightfoot
Unix Consultant
ISG Host Systems
Comcare
+61 2 62750680
Apologies for the rubbish that follows...
------------------------------------------------------------------------
NOTICE: This e-mail message and attachments may contain confidential
information. If you are not the intended recipient you should not use or
disclose any information in the message or attachments. If received in
error, please notify the sender by return email immediately. Comcare
does not waive any confidentiality or privilege.
Received on Wed Mar 19 2003 - 16:37:15 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:14:09 MST