Package: squid3 Version: 3.1.20-2.2+deb7u2 Severity: important Dear Maintainer, we use squid with 2 cache_peer proxies as upstream. Squid is used both as transparent and non-transparent proxy. After Upgrade from Version 3.1.20-2.2+deb7u2 to 3.1.20-2.2+deb7u3 we noticed a assertion failed in cache log for tunnel.cc and the info in /var/log/messages that the squid child was restarted.
Here are the last 50 lines from cache.log with Debug,9 2015/09/10 14:01:54.778| Adding deferred read on FD 478 2015/09/10 14:01:54.778| cbdataLock: 0x7f935cd1bc48=1 2015/09/10 14:01:54.778| cbdataLock: 0x7f935cd1bc48=2 2015/09/10 14:01:54.778| The AsyncCall DeferredReadManager::CloseHandler constructed, this=0x7f935e87d970 [call36278] 2015/09/10 14:01:54.778| cbdataLock: 0x7f935cd1bc48=3 2015/09/10 14:01:54.778| cbdataUnlock: 0x7f935cd1bc48=2 2015/09/10 14:01:54.778| cbdataUnlock: 0x7f935cd1bc48=1 2015/09/10 14:01:54.778| comm_add_close_handler: FD 478, AsyncCall=0x7f935e87d970*1 2015/09/10 14:01:54.778| cbdataUnlock: 0x7f935ec42ae8=12 2015/09/10 14:01:54.778| cbdataUnlock: 0x7f935ec42ae8=11 2015/09/10 14:01:54.778| cbdataUnlock: 0x7f935ec42ae8=10 2015/09/10 14:01:54.778| cbdataReferenceValid: 0x7f935ec42ae8 2015/09/10 14:01:54.778| HttpStateData status out: [ job2475] 2015/09/10 14:01:54.778| leaving HttpStateData::readReply(FD 478, data=0x7f935ec42ae8, size=16383, buf=0x7f935ec12500) 2015/09/10 14:01:54.778| cbdataUnlock: 0x7f935ec42ae8=9 2015/09/10 14:01:54.778| cbdataUnlock: 0x7f935ec42ae8=8 2015/09/10 14:01:54.778| entering SomeCommReadHandler(FD 187, data=0x7f935d7eb328, size=91, buf=0x7f935d7eb3f0) 2015/09/10 14:01:54.778| AsyncCall.cc(32) make: make call SomeCommReadHandler [call36242] 2015/09/10 14:01:54.778| cbdataReferenceValid: 0x7f935d7eb328 2015/09/10 14:01:54.778| cbdataReferenceValid: 0x7f935d7eb328 2015/09/10 14:01:54.778| tunnelReadClient: FD 187, read 91 bytes 2015/09/10 14:01:54.778| cbdataLock: 0x7f935d7eb328=9 2015/09/10 14:01:54.778| comm.cc(1196) commSetTimeout: FD 216 timeout 900 2015/09/10 14:01:54.778| cbdataLock: 0x7f935d7eb328=10 2015/09/10 14:01:54.778| cbdataLock: 0x7f935d7eb328=11 2015/09/10 14:01:54.778| The AsyncCall SomeTimeoutHandler constructed, this=0x7f935eccb450 [call36279] 2015/09/10 14:01:54.778| cbdataLock: 0x7f935d7eb328=12 2015/09/10 14:01:54.779| cbdataUnlock: 0x7f935d7eb328=11 2015/09/10 14:01:54.779| cbdataUnlock: 0x7f935d7eb328=10 2015/09/10 14:01:54.779| comm.cc(1207) commSetTimeout: FD 216 timeout 900 2015/09/10 14:01:54.779| cbdataUnlock: 0x7f935d7eb328=9 2015/09/10 14:01:54.779| cbdataReferenceValid: 0x7f935d7eb328 2015/09/10 14:01:54.779| cbdataUnlock: 0x7f935d7eb328=8 2015/09/10 14:01:54.779| tunnel.cc(488) copy: Schedule Write 2015/09/10 14:01:54.779| cbdataLock: 0x7f935d7eb328=9 2015/09/10 14:01:54.779| cbdataLock: 0x7f935d7eb328=10 2015/09/10 14:01:54.779| The AsyncCall TunnelBlindCopyWriteHandler constructed, this=0x7f935eb98800 [call36280] 2015/09/10 14:01:54.779| cbdataLock: 0x7f935d7eb328=11 2015/09/10 14:01:54.779| cbdataUnlock: 0x7f935d7eb328=10 2015/09/10 14:01:54.779| cbdataUnlock: 0x7f935d7eb328=9 2015/09/10 14:01:54.779| cbdataUnlock: 0x7f935d7eb328=8 2015/09/10 14:01:54.779| comm_write: FD 216: sz 91: asynCall 0x7f935eb98800*2 2015/09/10 14:01:54.779| commSetSelect(FD 216,type=2,handler=1,client_data=0x7f935681a808,timeout=0) 2015/09/10 14:01:54.779| leaving SomeCommReadHandler(FD 187, data=0x7f935d7eb328, size=91, buf=0x7f935d7eb3f0) 2015/09/10 14:01:54.779| cbdataUnlock: 0x7f935d7eb328=7 2015/09/10 14:01:54.779| entering SomeCommWriteHander(FD 486, data=0x7f935ed813a8, size=39, buf=0x7f935b8df6a8) 2015/09/10 14:01:54.779| AsyncCall.cc(32) make: make call SomeCommWriteHander [call36247] 2015/09/10 14:01:54.779| cbdataReferenceValid: 0x7f935ed813a8 2015/09/10 14:01:54.779| cbdataReferenceValid: 0x7f935ed813a8 2015/09/10 14:01:54.779| assertion failed: tunnel.cc:630: "from.len == 0" At the moment i have no chance to reproduce the issue, as this system is a live production system. After downgrading again to Version deb7u2 there is no assertion any more. Thanks for your help, Florian -- System Information: Debian Release: 7.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages squid3 depends on: ii adduser 3.113+nmu3 ii libc6 2.13-38+deb7u8 ii libcap2 1:2.22-1.2 ii libcomerr2 1.42.5-1.1+deb7u1 ii libdb5.1 5.1.29-5 ii libexpat1 2.1.0-1+deb7u2 ii libgcc1 1:4.7.2-5 ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u3 ii libk5crypto3 1.10.1+dfsg-5+deb7u3 ii libkrb5-3 1.10.1+dfsg-5+deb7u3 ii libldap-2.4-2 2.4.31-2 ii libltdl7 2.4.2-1.1 ii libpam0g 1.1.3-7.1 ii libsasl2-2 2.1.25.dfsg1-6+deb7u1 ii libstdc++6 4.7.2-5 ii libxml2 2.8.0+dfsg1-7+wheezy4 ii logrotate 3.8.1-4 ii lsb-base 4.1+Debian8+deb7u1 ii netbase 5.0 ii squid3-common 3.1.20-2.2+deb7u2 squid3 recommends no packages. Versions of packages squid3 suggests: pn resolvconf <none> ii smbclient 2:3.6.6-6+deb7u5 pn squid-cgi <none> pn squidclient <none> pn ufw <none> -- Configuration Files: /etc/logrotate.d/squid3 changed [not included] /etc/squid3/squid.conf changed [not included] -- no debconf information
