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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
