On 31/05/2016 9:56 p.m., Tomas Mozes wrote: > On Thu, May 26, 2016 at 8:04 AM, Amos Jeffries wrote: > >> On 24/05/2016 7:52 p.m., Tomas Mozes wrote: >>> Hello, >>> on two different squid servers I've observed a crash of pinger. First it >>> appeared on version 3.5.15 and later on version 3.5.17. >>> >>> Cache.log contains these lines: >>> >>> (pinger): Address.cc:671: void Ip::Address::getAddrInfo(addrinfo*&, int) >>> const: Assertion `false' failed. >>> 2016/05/14 21:55:25 kid1| Bad opcode: 112 from >>> [6661:6c73:6522:2061:7420:6c69:6e65:2036] >>> 2016/05/14 21:59:13 kid1| recv: (111) Connection refused >>> 2016/05/14 21:59:13 kid1| Closing Pinger socket on FD 17 >>> >>> On both servers, that IPv6 address was the same - >>> 6661:6c73:6522:2061:7420:6c69:6e65:2036 >>> >> >> That is the hexadecimal representation of the error: >> false" at line 6 >> >> Which means that your kernel is producing garbage when asked to resolve >> an IPv6 address or respond to an ICMPv6 packet. >> > > Cannot we prevent Squid from crashing in these cases? > Squid is not crashing. The pinger is. Squid continues with degraded service latency. What kind of continued operations would you expect a program to do when it discovers at least some portion of its RAM has been filled with garbage by the system kernel? Now cross your fingers and pray that no other programs on your whole system (network, if you did the same "disable" on other machines) are behaving badly in secret when given the garbage by the kernel like Squid's pinger was. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
