[squid-users] 4.10 crash

[Amos Jeffries]

On 26/02/20 8:46 pm, dm wrote:
> 26.02.2020 11:42, Dmitry Melekhov пишет:
>> Hello!
>>
>> see this in log, after this squid dies.
>>
>> 2020/02/26 11:17:47 kid1| UPGRADE WARNING: URL rewriter reponded with
>> garbage ' 192.168.23.54/ABDRASHITOV-RR.p98a3.belkam.com abdrashitovrr
>> CONNECT myip=192.168.22.254 myport=8090'. Future Squid wil
>> l treat this as part of the URL.

And guess what?

>From your access.log this is the URL:

>
http://detectportal.firefox.com/success.txt192.168.23.54/ABDRASHITOV-RR.p98a3.belkam.comabdrashitovrrGETmyip=192.168.22.254myport=8090


... so the helper is one thing you definitely need to get fixed.


>> 2020/02/26 11:17:48 kid1| assertion failed: MemBuf.cc:354: "new_cap >
>> (size_t) capacity"


This happened up to two seconds after the previous log entry. A great
many transactions may have passed in between the two occurances.


>>
>>
>> from systemctl status:
>>
>>
>> фев 26 11:17:48 inetgw2 squid[1167]: Squid Parent: squid-1 process
>> 11576 exited due to signal 6 with
>> фев 26 11:17:48 inetgw2 squid[1167]: Squid Parent: squid-1 process
>> 11576 will not be restarted for 3
>> фев 26 11:17:48 inetgw2 squid[1167]: Exiting due to repeated, frequent
>> failures
>>
>> I see this several times, have no idea what  caused this, even if this
>> is redirector error, squid should not crash...
>>
>> Is there any way to fix this?
>>

All the info we have now on the assertion is that the capacity value for
a memory buffer is trying to be grown into a negative size range (32-bit
overflow?). We will need a stack trace from assertion/crash to know
which buffer is being expanded and maybe find out why.

Details on how to get a stack traces are documented at
<https://wiki.squid-cache.org/SquidFaq/BugReporting>. That includes from
core files, or from a running proxy without affecting uptime any worse
than the crash already does.


Amos