[squid-users] pinger crash - Bad opcode: 112

Amos Jeffries squid3 at treenet.co.nz
Wed Jun 1 11:53:08 UTC 2016

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.


More information about the squid-users mailing list