> 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.
