Re: [squid-users] assertion failed

[Henrik Nordstrom]

On fre, 2008-07-11 at 00:27 +0545, Pritam wrote:
> Hi,
> 
> My squid box was restarted with following message in cache.log.
> 
> httpReadReply: Excess data from "HEAD 
> http://dl_dir.qq.com/qqfile/ims/qqdoctor/tsfscan.dat";
> assertion failed: forward.c:109: "!EBIT_TEST(e->flags, ENTRY_FWD_HDR_WAIT)"
> Starting Squid Cache version 2.7.STABLE3 for i686-pc-linux-gnu...
> Process ID 22147
> With 8192 file descriptors available...
> 
> I googled the issue and couldn't actually get the clearer idea behind.

You found a bug.

Please file a bug report. If you can please include a stacktace of that
error.. 

http://wiki.squid-cache.org/SquidFaq/TroubleShooting#head-7067fc0034ce967e67911becaabb8c95a34d576d

Regards
Henrik



signature.asc
Description: This is a digitally signed message part

Re: [squid-users] assertion failed

[Dave]

I get this one too, sorry do not have a coredump of it though.

Henrik Nordstrom wrote:

On fre, 2008-07-11 at 00:27 +0545, Pritam wrote:
  

Hi,

My squid box was restarted with following message in cache.log.

httpReadReply: Excess data from "HEAD 
http://dl_dir.qq.com/qqfile/ims/qqdoctor/tsfscan.dat";

assertion failed: forward.c:109: "!EBIT_TEST(e->flags, ENTRY_FWD_HDR_WAIT)"
Starting Squid Cache version 2.7.STABLE3 for i686-pc-linux-gnu...
Process ID 22147
With 8192 file descriptors available...

I googled the issue and couldn't actually get the clearer idea behind.



You found a bug.

Please file a bug report. If you can please include a stacktace of that
error.. 


http://wiki.squid-cache.org/SquidFaq/TroubleShooting#head-7067fc0034ce967e67911becaabb8c95a34d576d

Regards
Henrik

  

Re: [squid-users] assertion failed

[Henrik Nordstrom]

On mån, 2008-07-14 at 20:04 +0545, pritam wrote:
> Hi All,
> 
> Knowing that it is a bug ( ..? ) I need yours help here.
> 
> My squid is getting restarted often (2, 3 times a day) with following 
> messages:
> 
> 2008/07/14 07:56:47| assertion failed: store_client.c:172: 
> "!EBIT_TEST(e->flags, ENTRY_ABORTED)"
> 2008/07/14 17:18:17| assertion failed: forward.c:109: 
> "!EBIT_TEST(e->flags, ENTRY_FWD_HDR_WAIT)"

That's a bug.

Please file a bug with a stack trace of the error:

http://wiki.squid-cache.org/SquidFaq/TroubleShooting#head-7067fc0034ce967e67911becaabb8c95a34d576d

> I have recently updated my squid to 2.7ST3 in two of my servers (one in 
> Fedora 6, other in CentOS 5.1) and also implemented COSS. The above 
> problem is seen in only one of my server ( running CentOS 5.1).

Do you see the same with 2.7.STABLE2?

> Is this related to COSS...? Or it has to do something with OS 
> Installed...? Or related to squid 2.7ST3, because I had no such issue 
> before with squid 2.6.

There is a suspicion one of the changes in 2.7.STABLE3 is causing
this... but nothing confirmed yet.

Regards
Henrik

Re: [squid-users] assertion failed

[pritam]

Dear Henrik,

Thank you very much for your response.

I haven't  try with 2.7-ST2. But now I will.

Regards,

Pritam 


Henrik Nordstrom wrote:

Do you see the same with 2.7.STABLE2?

There is a suspicion one of the changes in 2.7.STABLE3 is causing
this... but nothing confirmed yet.

Regards
Henrik

  

Re: [squid-users] assertion failed?

[Robert Collins]

On Tue, 2003-02-11 at 23:50, [EMAIL PROTECTED] wrote:
> I've got one squid 2.4.STABLE1 server which keeps falling over with
> the following error:
> 
> 2003/02/10 16:43:50| ctx: enter level  0: 'http://www.dhl.com/popup.html'
> 2003/02/10 16:43:50| assertion failed: refresh.c:163: "age >= 0"
> 
> It then fails to process any further requests.
> Is there any way to fix this without upgrading software version?

Run it under a debugger and analyse the problem. 

However, I *really* recommend upgrading.
Squid 2.4S6 is the *minimum* version of squid free of known security
bugs.

Squid 2.5StableX is the minimum actively gratis supported and bugfixed
version.

Squid 3.0 is about to begin the prerelease cycle.

Rob
-- 
GPG key available at: .



signature.asc
Description: This is a digitally signed message part

Re: [squid-users] assertion failed?

[Marc Elsen]

"[EMAIL PROTECTED]" wrote:
> 
> I've got one squid 2.4.STABLE1 server which keeps falling over with
> the following error:
> 
> 2003/02/10 16:43:50| ctx: enter level  0: 'http://www.dhl.com/popup.html'
> 2003/02/10 16:43:50| assertion failed: refresh.c:163: "age >= 0"
> 
> It then fails to process any further requests.
> Is there any way to fix this without upgrading software version?

 I heard developers reporting that 2.4 support is  fading out.
 You may want to upgrade to :

   2.5S1

 M.

> 
> Paul

-- 

 'Time is a consequence of Matter thus
 General Relativity is a direct consequence of QM
 (M.E. Mar 2002)

Re: [squid-users] assertion failed

[Henrik Nordstrom]

tis 2006-07-25 klockan 10:33 +0300 skrev Hamed Adel:

> The errors:
> - assertion failed: client_side.c:2485: "i->prefix_size > 0"

The above is bug #1670

> - assertion failed: http.c:1182: "strstr(url, strBuf(request->urlpath))"

And this is bug #1660


Both will be fixed in the upcoming 2.6.STABLE2 bugfix release.

Patches for both issues is available from
http://www.squid-cache.org/Versions/v2/2.6/changesets/ or included in
the nightly snapshot release if you need to get these corrected before
2.5.STABLE2 is available.

2.6.STABLE2 will most likely be released in the upcoming weekend.

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel

RE: [squid-users] assertion failed

[Hamed Adel]

Hi henrik

Thank you fro your help waiting the squid 2.6.2

Eng . Hamed Adel
Senior Network Engineer
Mail: [EMAIL PROTECTED]
Tel :  +2 0502528897
Mob: +2 0103503888
Fax:   +2 0502528897
Web site: www.egyptnetwork.com 


-Original Message-
From: Henrik Nordstrom [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 25, 2006 7:47 PM
To: Hamed Adel
Cc: squid-users@squid-cache.org
Subject: Re: [squid-users] assertion failed

tis 2006-07-25 klockan 10:33 +0300 skrev Hamed Adel:

> The errors:
> - assertion failed: client_side.c:2485: "i->prefix_size > 0"

The above is bug #1670

> - assertion failed: http.c:1182: "strstr(url, strBuf(request->urlpath))"

And this is bug #1660


Both will be fixed in the upcoming 2.6.STABLE2 bugfix release.

Patches for both issues is available from
http://www.squid-cache.org/Versions/v2/2.6/changesets/ or included in
the nightly snapshot release if you need to get these corrected before
2.5.STABLE2 is available.

2.6.STABLE2 will most likely be released in the upcoming weekend.

Regards
Henrik

Re: [squid-users] assertion failed

[Murugan]

visit this link

http://www.squid-cache.org/mail-archive/squid-users/200309/0849.html

Regrads
-Murugan

- Original Message -
From: "Danish Khan" <[EMAIL PROTECTED]>
To: "'Henrik Nordstrom'" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, May 06, 2004 11:58 AM
Subject: [squid-users] assertion failed


>
> My squid almost dies after every 15 mins giving the below error.
>
> assertion failed: errorpage.c:292: "mem->inmem_hi == 0"
>
> Using squid stable 5 on Sun Linux. I have found its patch kindly tell me
how
> to apply its patch.
>
>
> Danish khan
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.670 / Virus Database: 432 - Release Date: 4/27/2004

RE: [squid-users] assertion failed

[Danish Khan]

Well page gets open but the associated link
http://sourceforge.net/tracker/index.php?func=detail&aid=651877&group_id=477
37&atid=450621 is not opening kindly if u tell me the details how to invoke
this and where is squid-icap 

Regards,
Danish Khan 


-Original Message-
From: Murugan [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 06, 2004 12:14 PM
To: [EMAIL PROTECTED]
Subject: Re: [squid-users] assertion failed


visit this link

http://www.squid-cache.org/mail-archive/squid-users/200309/0849.html

Regrads
-Murugan

- Original Message -
From: "Danish Khan" <[EMAIL PROTECTED]>
To: "'Henrik Nordstrom'" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, May 06, 2004 11:58 AM
Subject: [squid-users] assertion failed


>
> My squid almost dies after every 15 mins giving the below error.
>
> assertion failed: errorpage.c:292: "mem->inmem_hi == 0"
>
> Using squid stable 5 on Sun Linux. I have found its patch kindly tell me
how
> to apply its patch.
>
>
> Danish khan
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.670 / Virus Database: 432 - Release Date: 4/27/2004

Re: [squid-users] assertion failed

[Henrik Nordstrom]

On Thu, 6 May 2004, Danish Khan wrote:

> My squid almost dies after every 15 mins giving the below error. 
> 
> assertion failed: errorpage.c:292: "mem->inmem_hi == 0"
> 
> Using squid stable 5 on Sun Linux. I have found its patch kindly tell me how
> to apply its patch.

Patches is applied to the Squid sources using the patch command.

Regards
Henrik

Re: [squid-users] assertion failed: disk.cc

[Henrik Nordstrom]

On fre, 2008-08-01 at 15:56 +0900, hideck wrote:

> 2008/08/01 15:18:04| assertion failed: disk.cc:242: "fdd->write_q->len
> > fdd->write_q->buf_offset"
> 2008/08/01 15:18:07| Starting Squid Cache version 3.0.STABLE7 for
> i686-redhat-linux-gnu...
> 
> I am using coss with squid3.0 STABLE7 on the RHEL4(x86) server.
> The setting of my coss is this.

COSS in Squid-3.0 is highly experimental and known to be quite buggy..

Regards
Henrik

Re: [squid-users] assertion failed: errorpage.cc

[Brett Lymn]

On Wed, Jul 24, 2013 at 06:29:26AM +, mdeche...@comcast.net wrote:
>
> My take on all this is that it appears the server may be starved for memory.  
> I have seen other strange behaviors such mysqld, squid, and pptpd daemons 
> dying randomly.  I've seen squid daemon restart for reasons unknown (though 
> the above cache.log suggests a cache digest rebuild every 3600 seconds).
> 

You think?  From that config you have told squid to reserve half the
memory on the system for cache, on top of which you tell it to create a
16GB cache which takes about 10MB per GB of memory to manage and then on
top of that you run mysql and other stuff.

> Are there any obvious mistakes I've made here?  I do plan to run my 
> production proxy with more memory and am not in objection to adding more 
> memory to this environment, but would like to do so with an understanding of 
> the issues before moving forward.
> 

I think you need to read this first:

http://wiki.squid-cache.org/SquidFaq/SquidMemory

You definitely want to put more memory in the machine, the more the
better... (up to a point since you are using 32 bit).

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."

Re: [squid-users] assertion failed: errorpage.cc

[Amos Jeffries]

On 24/07/2013 6:29 p.m., mdeche...@comcast.net wrote:

Hello Squid Users --

I'm very new to running squid.  I've quickly learned that there are many 
parameters to configure and therefore many places problems can occur.


FYI: quite a few will be picked up by squid -k parse.


I am prototyping a squid environment on a CentOS 6.4 32-bit system with 256MB 
RAM.  Presently, I'm observing strange behavior with the proxy, and the most 
notable symptom is that either the proxy server becomes unavailable after a 
period of time or DNS names stop resolving.  I should mention that I'm also 
sending the traffic over a Poptop (pptpd) VPN tunnel, but these issues persist 
even without the tunnel up as far as I can tell.

Info from the environment:

# squid -v
Squid Cache: Version 3.1.10


3.1 is quite old now. A lot has improved since then. Please consider 
upgrading if you can.



configure options:  '--build=i386-redhat-linux-gnu' 
'--host=i386-redhat-linux-gnu' '--target=i686-redhat-linux-gnu' 
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' 
'--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' 
'--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' 
'--sharedstatedir=/var/lib' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--enable-internal-dns' 
'--disable-strict-error-checking' '--exec_prefix=/usr' 
'--libexecdir=/usr/lib/squid' '--localstatedir=/var' 
'--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' 
'--with-logdir=$(localstatedir)/log/squid' 
'--with-pidfile=$(localstatedir)/run/squid.pid' '--disable-dependency-tracking' 
'--enable-arp-acl' '--enable-follow-x-forwarded-for' 
'--enable-auth=basic,digest,ntlm,negotiate' 
'--enable-basic-auth-helpers=LDAP,MSNT,NCSA,PAM,SMB,YP,getpwnam,multi-domain-NTLM,SASL,DB,POP3,squid_radius_auth'
 '--enable-ntlm-auth-helpers=smb_lm,no_check,fakeauth' 
'--enable-digest-auth-helpers=password,ldap,eDirectory' 
'--enable-negotiate-auth-helpers=squid_kerb_auth' 
'--enable-external-acl-helpers=ip_user,ldap_group,session,unix_group,wbinfo_group'
 '--enable-cache-digests' '--enable-cachemgr-hostname=localhost' 
'--enable-delay-pools' '--enable-epoll' '--enable-icap-client' 
'--enable-ident-lookups' '--with-large-files' '--enable-linux-netfilter' 
'--enable-referer-log' '--enable-removal-policies=heap,lru' '--enable-snmp' 
'--enable-ssl' '--enable-storeio=aufs,diskd,ufs' '--enable-useragent-log' 
'--enable-wccpv2' '--enable-esi' '--with-aio' '--with-default-user=squid' 
'--with-filedescriptors=16384' '--with-dl' '--with-openssl' '--with-pthreads' 
'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 
'target_alias=i686-redhat-linux-gnu' 'CFLAGS=-O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables -fpie' 'LDFLAGS=-pie' 'CXXFLAGS=-O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables -fpie' 
--with-squid=/builddir/build/BUILD/squid-3.1.10

squid.conf:

http_port 3128 intercept
http_port 4334
http_port 127.0.0.1:33699
http_port 127.0.0.1:32623
http_port 127.0.0.1:26226
http_port 127.0.0.1:26499
http_port 127.0.0.1:18108
http_port 127.0.0.1:49236
http_port MY.PUB.IP.ADR:3128


You have already opened port 3128 on all IP addresses the box has, up 
there with "intercept" flag on it. That is what the commBind error in 
your log is about.


Your main forward-proxy port is 4334 on all IP addresses.

FWIW: I suggest that you swap those around so 3128 is your main port and 
4334 is the one receiving the intercepted traffic.




icp_port 0

refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern .0 20% 4320
acl apache rep_header Server ^Apache

cache_mem 128 MB
maximum_object_size 1024 KB
maximum_object_size_in_memory 16 KB
cache_dir aufs /opt/squid/cache 16384 64 256

error_directory /opt/squid/logs


Er. You have your error page templates in a directory called "logs" ??
Probably remove that line completely for now. The defaults should be 
able to work well enough until you read up on it a bit.



allow_underscore off
refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern .   0   20% 4320

acl Safe_ports port 80  # http
acl Safe_ports port 443 # https
acl Safe_ports port 21  # ftp
acl Safe_ports port 554 # rtsp

http_access deny !Safe_ports

## authentication

auth_param basic program /usr/lib/squid/squid_db_auth --user  
--password  --plaintext --persist --dsn DBI:mysql:database=the_database
auth_param basic children 5
auth_param basic realm Web-Proxy
auth_param basic credentialsttl 1 minute
auth_param basic casesensitive off

acl db-auth proxy_auth REQUIRED
http_access allow db-auth
http_access deny all

cache_mgr thisi...@asite.com

httpd_su

Re: [squid-users] assertion failed: errorpage.cc

[mdecheser]

> I think you need to read this first:
> 
> http://wiki.squid-cache.org/SquidFaq/SquidMemory
> 
> You definitely want to put more memory in the machine, the more the
> better... (up to a point since you are using 32 bit).

The link was definitely helpful in helping me tune the config, but it did not 
address the specific problem I posted about.  I turned up logging using 
debug_options ALL,9 in the config, recycled, and found this:

2013/07/26 09:11:11.515| errorpage.cc(1048) BuildContent: No existing error 
page language negotiated for ERR_ACCESS_DENIED. Using default error file.
2013/07/26 09:11:11.515| assertion failed: errorpage.cc:1064: 
"(size_t)content->contentSize() == strlen(content->content())"

In the config, I had:

error_directory /opt/squid/logs

Turns out Squid was crashing because it couldn't find error pages.  I changed 
this to point to where the squid RPM keeps the error files (at least for CentOS 
6 / squid -v 3.1.10):

error_directory /usr/share/squid/errors/en

After correcting that entry in the config and recycling Squid, the error 
message has not reappeared, Squid has not crashed and has been otherwise stable 
(along with new, correctly sized cache_mem and cache_dir settings :) ).

Cheers,
MD

Re: [squid-users] Assertion Failed Error

[Marc Elsen]

Asif Sadiq wrote:
> 
> Hi,
> 
> I have been running 2.4STABLE7 for almost a year now - and I have recently
> had an "assertion failed" error which has caused squid to restart:
> 
> 2003/03/27 10:38:20| assertion failed: comm.c:582: "fd < Squid_MaxFD"
> 2003/03/27 10:38:32| Starting Squid Cache version 2.4.STABLE7 for
> sparc-sun-solaris2.8...
> 2003/03/27 10:38:32| Process ID 7936
> 2003/03/27 10:38:32| With 16384 file descriptors available
> 
> I have ample file descriptors available... and never is there more than
> 100 open at any one time.  What is the possible cause of this failure?

 Difficult to say  bug and/or failure on internal consistency
 check, unforeseen condition in the software...

 If this problem keeps bothering you, please upgrade to the
 latest squid release (2.5S2).

 M.

> 
> Regards,
> 
> Asif.
> 
> 
> Asif Sadiq
> 
> Network Engineer
> Integrated Network Solutions
> NEC Europe Ltd.
> 
> E-mail: [EMAIL PROTECTED]
> 
> 

-- 

 'Time is a consequence of Matter thus
 General Relativity is a direct consequence of QM
 (M.E. Mar 2002)

Re: [squid-users] Assertion Failed Error

[Henrik Nordstrom]

http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.19
and
http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.20

Regards
Henrik



tor 2003-03-27 klockan 13.14 skrev Asif Sadiq:
> Hi,
> 
> I have been running 2.4STABLE7 for almost a year now - and I have recently
> had an "assertion failed" error which has caused squid to restart:
> 
> 2003/03/27 10:38:20| assertion failed: comm.c:582: "fd < Squid_MaxFD"
> 2003/03/27 10:38:32| Starting Squid Cache version 2.4.STABLE7 for
> sparc-sun-solaris2.8...
> 2003/03/27 10:38:32| Process ID 7936
> 2003/03/27 10:38:32| With 16384 file descriptors available
> 
> 
> I have ample file descriptors available... and never is there more than
> 100 open at any one time.  What is the possible cause of this failure?
> 
> Regards,
> 
> Asif.
> 
> 
> Asif Sadiq
> 
> Network Engineer
> Integrated Network Solutions
> NEC Europe Ltd.
> 
> E-mail: [EMAIL PROTECTED]
> 
> 
-- 
Henrik Nordstrom <[EMAIL PROTECTED]>
MARA Systems AB, Sweden

Re: [squid-users] Assertion failed problem

[Marc Elsen]

Linda Pronk-Markus wrote:
> 
> I am running Squid Web Proxy Cache 2.5 for some time now, but today I

  Which version of squid are you using ?
  Check cache.log upon squid startup.
  
  M.

> encountered a problem. The squidNT service stopped and when starting again
> it immediately stopped again.
> I then analyzed the logfiles and in the cache-logfile I found this:
> 
> assertion failed: C:\work\nt-2.5\src\comm_select.c:838: "readfds.fd_count <=
> (unsigned int)
> 
> I have searched your site and other internetsites about Squid, but I
> could'nt find this error.
> 
> Could you please help me with this problem ?
> By the way, I temporarely solved this problem by booting the server on which
> this service is installed.
> 
> With kind regards,
> 
> Linda Pronk-Markus
> 
> E-mail adress: [EMAIL PROTECTED]
> 
> **
> Aan dit bericht kunnen geen rechten worden ontleend. Het bericht is alleen bestemd
> voor de geadresseerde. Indien dit bericht niet voor u is bestemd, verzoeken wij u dit
> onmiddellijk aan ons te melden en de inhoud van het bericht te
> vernietigen.
> **
> The contents of this email and any attachments are confidential. It is intended for 
> the
> named recipient(s) only. If you have received this email in error please notify the
> system manager or  the sender immediately and do not disclose the contents to any
> one or make copies.
> **

-- 

 'Love is truth without any future.
 (M.E. 1997)

Re: [squid-users] Assertion failed problem

[Marc Elsen]

Linda Pronk-Markus wrote:
> 
> Marc,
> 
> I am using version 2.5.STABLE1.NT-CVS for i686-pc-winnt
> 
> Greetings,
> 
> Linda
> 
 
 Ok,perhaps upgrading to 2.5.STABLE3 will help you.

 M.

Re: [squid-users] assertion failed: DestinationIp.cc

[Amos Jeffries]

On 2014-03-05 01:28, Nil Nik wrote:

I am using ICAP and squid 3.3.9
After some interval I got following messages in cache.log and squid get 
stop.


2014/03/04 16:01:35 kid1| ACL::checklistMatches WARNING:
'http_denied_status' ACL is used but there is no HTTP reply -- not
matching.
2014/03/04 16:01:35 kid1| ACL::checklistMatches WARNING:
'http_denied_status' ACL is used but there is no HTTP reply -- not
matching.
2014/03/04 16:01:35 kid1| ACL::checklistMatches WARNING:
'http_denied_status' ACL is used but there is no HTTP reply -- not
matching.
2014/03/04 16:01:35 kid1| ACL::checklistMatches WARNING:
'http_denied_status' ACL is used but there is no HTTP reply -- not
matching.
2014/03/04 16:01:35 kid1| ACL::checklistMatches WARNING:
'http_denied_status' ACL is used but there is no HTTP reply -- not
matching.
2014/03/04 16:01:35 kid1| assertion failed: DestinationIp.cc:58:
"checklist->conn() && checklist->conn()->clientConnection != NULL"

How do i resolve this issue?


What is your current squid.conf content?

Amos

RE: [squid-users] Assertion failed messages

[Elsen Marc]

 
> All,
> 
> My apologize if this question was discussed before.
> 
> Seems my Squid (2.5S9 + patches, kernel 2.4.30, aufs, 
> ReiserFS) restart by
> itself so often with message:
> 
> assertion failed: store_swapout.c:232: "mem->inmem_lo == 0"
> 
> Need your advise.
> 
> Thx & Rgds,
> 
 
  http://www.mail-archive.com/squid-dev@squid-cache.org/msg02756.html

  M.

Re: [squid-users] Assertion failed messages

[Henrik Nordstrom]

On Fri, 22 Apr 2005, Awie wrote:
All,
My apologize if this question was discussed before.
Seems my Squid (2.5S9 + patches, kernel 2.4.30, aufs, ReiserFS) restart by
itself so often with message:
assertion failed: store_swapout.c:232: "mem->inmem_lo == 0"
This should be fixed in the current set of patches. Was problems with the 
2GB patch some days ago.

Regards
Henrik

Re: [squid-users] Assertion failed messages

[Awie]

> >
> > assertion failed: store_swapout.c:232: "mem->inmem_lo == 0"
>
> This should be fixed in the current set of patches. Was problems with the
> 2GB patch some days ago.

Henrik,

Few hours ago, I limited the patches, the 2 GB patch was excluded. The
result is; Squid runs very well.

I will try to re-download all patches again though I already did it 2-3 days
ago.

Thanks for your advise.

Thx & Rgds,

Awie

Re: [squid-users] Assertion failed messages

[Henrik Nordstrom]

On Fri, 22 Apr 2005, Awie wrote:
assertion failed: store_swapout.c:232: "mem->inmem_lo == 0"
This should be fixed in the current set of patches. Was problems with the
2GB patch some days ago.
Henrik,
Few hours ago, I limited the patches, the 2 GB patch was excluded. The
result is; Squid runs very well.
I will try to re-download all patches again though I already did it 2-3 days
ago.
The patch page tells you the date each patch was last updated.
REgards
Henrik

Re: [squid-users] Assertion failed messages

[Awie]

> >>> assertion failed: store_swapout.c:232: "mem->inmem_lo == 0"
> >>
> >> This should be fixed in the current set of patches. Was problems with
the
> >> 2GB patch some days ago.
> >
> > Henrik,
> >
> > Few hours ago, I limited the patches, the 2 GB patch was excluded. The
> > result is; Squid runs very well.
> >
> > I will try to re-download all patches again though I already did it 2-3
days
> > ago.
>
> The patch page tells you the date each patch was last updated.
>
> REgards
> Henrik

Yes, it is. I downloaded all patches at 1:14 PM my local time (GMT 5.14 am)
on April 20. So, I did it earlier than patch fixing.

Now, I just applied the new patch and Squid seem run normally.

Thx & Rgds,

Awie

Re: [squid-users] assertion failed: cbdata.cc

[Serassio Guido]

Hi,

At 21.25 10/06/2005, Sam Reynolds wrote:

Received this error using Squid Cache version 3.0-PRE3-20050609 on Fedora 
Core 1.


Jun 10 15:20:39  squid[1527]: assertion failed: cbdata.cc:118: 
"cookie == ((long)this ^ Cookie)"


Looked in the Bug list and did not see this as a known bug.  Any 
assistance would be greatly appreciated.


So, please, open a new bug on bugzilla with the description of how trigger 
the problem.


Regards

Guido



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/

Re: [squid-users] assertion failed: cbdata.cc

[Serassio Guido]

Hi,

At 21.25 10/06/2005, Sam Reynolds wrote:

Received this error using Squid Cache version 3.0-PRE3-20050609 on Fedora 
Core 1.


Jun 10 15:20:39  squid[1527]: assertion failed: cbdata.cc:118: 
"cookie == ((long)this ^ Cookie)"


Looked in the Bug list and did not see this as a known bug.  Any 
assistance would be greatly appreciated.


Same problem as the bug #1126 (closed due to inactivity).
http://www.squid-cache.org/bugs/show_bug.cgi?id=1126

Please, reopen this bug and, if possible, attach a stack trace.
http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.19

Regards

Guido



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/

Re: [squid-users] assertion failed: forward.c

[Henrik Nordstrom]

mån 2007-05-21 klockan 12:05 +0800 skrev Yoseph Basri:
> Hi,
> 
> My squid box got restart after receive  assertion failed: forward.c:
> 
> 2007/05/20 09:48:51| assertion failed: forward.c:742: "fd ==
> fwdState->server_fd"
> 2007/05/20 09:49:01| Starting Squid Cache version 2.5.STABLE14 for
> i686-pc-linux-gnu..

Please file a bug report. Don't forget to include a backtrace.

http://wiki.squid-cache.org/SquidFaq/TroubleShooting#head-7067fc0034ce967e67911becaabb8c95a34d576d

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel

Re: [squid-users] assertion failed stmem.cc

[Henrik Nordstrom]

fre 2003-09-12 klockan 07.10 skrev Joshua Brindle:
> I got three of these assertion failures very close to one another here
> this is squid-3.0-PRE3-20030904

> 2003/09/11 21:39:25.379| assertion failed: stmem.cc:230: "0"

There is a open bug report for this issue. See the Squid bugzilla
database and please add your info to the existing report.

Regards
Henrik

-- 
Donations welcome if you consider my Free Squid support helpful.
https://www.paypal.com/xclick/business=hno%40squid-cache.org

Please consult the Squid FAQ and other available documentation before
asking Squid questions, and use the squid-users mailing-list when no
answer can be found. Private support questions is only answered
for a fee or as part of a commercial Squid support contract.

If you need commercial Squid support or cost effective Squid and
firewall appliances please refer to MARA Systems AB, Sweden
http://www.marasystems.com/, [EMAIL PROTECTED]

Re: [squid-users] assertion failed in COSS

[Amos Jeffries]

On 14/01/11 01:38, Hasanen AL-Bana wrote:

Hi,

I am getting these every few minutes causing squid process to restart

2011/01/08 17:30:20| assertion failed: coss/store_dir_coss.c:276:
"curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
2011/01/08 17:36:44| assertion failed: coss/store_dir_coss.c:276:
"curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
2011/01/08 17:43:14| assertion failed: coss/store_dir_coss.c:276:
"curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
2011/01/08 17:50:19| assertion failed: coss/store_dir_coss.c:276:
"curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
2011/01/08 17:57:17| assertion failed: coss/store_dir_coss.c:276:
"curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
2011/01/08 18:04:40| assertion failed: coss/store_dir_coss.c:276:
"curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
2011/01/08 18:11:25| assertion failed: coss/store_dir_coss.c:276:
"curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"

The system has about 1TB of 15K SAS Disks with 32GB of RAM.

here are my cache_dir settings :


cache_dir coss /mnt/cachedisk1/coss/store1 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk1/coss/store2 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk1/coss/store3 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk1/coss/store4 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk1/coss/store5 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096

cache_dir coss /mnt/cachedisk2/coss/store1 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk2/coss/store2 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk2/coss/store3 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk2/coss/store4 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk2/coss/store5 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096

When I disabled most of the cache_dirs the system worked just fine ,
is there any issue with having lots of coss cache_dirs ?


You are out on/past the edges of known configurations there already. 
Most mentions here have been from people using only a few cache_dir, 
mixing aufs for bugger objects with a COSS or two to speed up the small 
items.


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.10
  Beta testers wanted for 3.2.0.4

Re: [squid-users] assertion failed in COSS

[Hasanen AL-Bana]

Hi Amos,

I already have other aufs disks in my configuration :

here is my full cache_dir config file : (i have cache_dir(s) is a
separate config file)

cache_dir coss /mnt/cachedisk1/coss/store1 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk1/coss/store2 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk1/coss/store3 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk1/coss/store4 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk1/coss/store5 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk2/coss/store1 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk2/coss/store2 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk2/coss/store3 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk2/coss/store4 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk2/coss/store5 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir aufs /mnt/cachedisk3/cache/store1 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store2 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store3 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store4 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store5 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store6 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store7 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store8 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store9 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store10 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store11 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store12 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store13 2 16 256
cache_dir aufs /mnt/cachedisk3/cache/store14 2 16 256
cache_dir coss /mnt/cachedisk4/coss/store4 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk4/coss/store4 5 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir coss /mnt/cachedisk4/coss/store4 2 max-size=100
maxfullbufs=4 membufs=20 block-size=4096
cache_dir aufs /mnt/cachedisk5/cache/store1 1 16 256
cache_dir aufs /mnt/cachedisk5/cache/store2 1 16 256
cache_dir aufs /mnt/cachedisk5/cache/store3 1 16 256
cache_dir aufs /mnt/cachedisk5/cache/store4 1 16 256
cache_dir aufs /mnt/cachedisk5/cache/store5 1 16 256
cache_dir aufs /mnt/cachedisk5/cache/store6 1 16 256

in fact , I have another system (Dell PE R510 4x300GB 15K SAS 24GB
RAM) and it is running just fine with 10 COSS files (50 GB each) and a
bunch of AUFS directories.

On Thu, Jan 13, 2011 at 4:52 PM, Amos Jeffries  wrote:
> On 14/01/11 01:38, Hasanen AL-Bana wrote:
>>
>> Hi,
>>
>> I am getting these every few minutes causing squid process to restart
>>
>> 2011/01/08 17:30:20| assertion failed: coss/store_dir_coss.c:276:
>> "curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
>> 2011/01/08 17:36:44| assertion failed: coss/store_dir_coss.c:276:
>> "curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
>> 2011/01/08 17:43:14| assertion failed: coss/store_dir_coss.c:276:
>> "curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
>> 2011/01/08 17:50:19| assertion failed: coss/store_dir_coss.c:276:
>> "curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
>> 2011/01/08 17:57:17| assertion failed: coss/store_dir_coss.c:276:
>> "curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
>> 2011/01/08 18:04:40| assertion failed: coss/store_dir_coss.c:276:
>> "curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
>> 2011/01/08 18:11:25| assertion failed: coss/store_dir_coss.c:276:
>> "curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"
>>
>> The system has about 1TB of 15K SAS Disks with 32GB of RAM.
>>
>> here are my cache_dir settings :
>>
>>
>> cache_dir coss /mnt/cachedisk1/coss/store1 5 max-size=100
>> maxfullbufs=4 membufs=20 block-size=4096
>> cache_dir coss /mnt/cachedisk1/coss/store2 5 max-size=100
>> maxfullbufs=4 membufs=20 block-size=4096
>> cache_dir coss /mnt/cachedisk1/coss/store3 5 max-size=100
>> maxfullbufs=4 membufs=20 block-size=4096
>> cache_dir coss /mnt/cachedisk1/coss/store4 5 max-size=100
>> maxfullbufs=4 membufs=20 block-size=4096
>> cache_dir coss /mnt/cachedisk1/coss/store5 5 max-size=100
>> maxfullbufs=4 membufs=20 block-size=4096
>>
>> cache_dir coss /mnt/cachedisk2/coss/store1 5 max-size=100
>> maxfullbufs=4 membufs=20 block-size=4096
>> cache_dir coss /mnt/cachedisk2/coss/store2 5 max-size=100
>> maxfullbufs=4 membufs=20 block-size=4096
>> cache_dir coss /mnt/cachedisk2/coss/store3 5 max-size=100
>> maxfullbufs=4 membufs=20 block-size=4096
>> cache_dir coss /mnt/cac

Re: [squid-users] assertion failed in COSS

[Ralf Hildebrandt]

> You are out on/past the edges of known configurations there already.

To boldly configure what nobody configured before: This is the mission
of Capt. Al-Bana :)

Re: [squid-users] assertion failed in COSS

[Henrik Nordström]

tor 2011-01-13 klockan 15:38 +0300 skrev Hasanen AL-Bana:
> Hi,
> 
> I am getting these every few minutes causing squid process to restart
> 
> 2011/01/08 17:30:20| assertion failed: coss/store_dir_coss.c:276:
> "curstripe == storeCossFilenoToStripe(cs, e->swap_filen)"

This is a bug.

A guess is that it's triggered by you trying to store largeish objects
in the COSS. COSS is designed for storing small objects only.  I would
not recommend using a max-size larger than at most 64K for COSS, and
would recommend 32K.

Regards
Henrik

Re: [squid-users] assertion failed: forward.c:109

[Amos Jeffries]

On Wed, 17 Feb 2010 13:07:25 +0200, Thomas 
wrote:
> Hi!
> 
> I recently installed Squid 2.7 Stable3 on a Ubuntu 8.10 Server (64-bit)
> box. However, since about two weeks ago, the following error started
> showing up (and it seems to appear more frequently now):
> 
> 2010/02/17 12:06:14| squidaio_queue_request: WARNING - Queue congestion
> 2010/02/17 12:07:49| clientTryParseRequest: FD 258 (10.55.2.104:3183)
> Invalid Request
> 2010/02/17 12:12:26| parseHttpRequest: Unsupported method
> 'ü¢Ÿº‚.¬×ëX;Wã—qNe±ôÞ…x®/rð`'
> 2010/02/17 12:12:26| clientTryParseRequest: FD 262 (172.50.3.6:2072)
> Invalid Request
> 2010/02/17 12:12:43| assertion failed: forward.c:109:
> "!EBIT_TEST(e->flags, ENTRY_FWD_HDR_WAIT)"
> 2010/02/17 12:12:46| Starting Squid Cache version 2.7.STABLE3 for
> amd64-debian-linux-gnu...
> 2010/02/17 12:12:46| Process ID 20045
> 2010/02/17 12:12:46| With 8192 file descriptors available
> 2010/02/17 12:12:46| Using epoll for the IO loop
> 
> Google yielded a response where somebody else had a similar problem The
> recommendation was to file a bug report.
> 
> Now:
> (1) Is there a fix for this available somewhere?
> (2) This distro also features Squid3.
> 
> Any recommendations? Remove Squid 2.7 and install 2.6 or remove 2.7 and
> install Squid3?


And the develpers/support first reaction is ... "please try the latest
release and verify that it still exists". Especially if you found prior
evidence of people reporting it.
 that means 2.7.STABLE7

Amos

Re: [squid-users] assertion failed: forward.c:109

[Thomas]

Did I really post such a stupid question to receive such a sarcastic
answer?

Thanks anyway.

Regards
Thomas
 


-Original Message-
From: Amos Jeffries 
To: Squid Users 
Subject: Re: [squid-users] assertion failed: forward.c:109
Date: Thu, 18 Feb 2010 10:45:48 +1300

On Wed, 17 Feb 2010 13:07:25 +0200, Thomas 
wrote:
> Hi!
> 
> I recently installed Squid 2.7 Stable3 on a Ubuntu 8.10 Server (64-bit)
> box. However, since about two weeks ago, the following error started
> showing up (and it seems to appear more frequently now):
> 
> 2010/02/17 12:06:14| squidaio_queue_request: WARNING - Queue congestion
> 2010/02/17 12:07:49| clientTryParseRequest: FD 258 (10.55.2.104:3183)
> Invalid Request
> 2010/02/17 12:12:26| parseHttpRequest: Unsupported method
> 'ü¢Ÿº‚.¬×ëX;Wã—qNe±ôÞ…x®/rð`'
> 2010/02/17 12:12:26| clientTryParseRequest: FD 262 (172.50.3.6:2072)
> Invalid Request
> 2010/02/17 12:12:43| assertion failed: forward.c:109:
> "!EBIT_TEST(e->flags, ENTRY_FWD_HDR_WAIT)"
> 2010/02/17 12:12:46| Starting Squid Cache version 2.7.STABLE3 for
> amd64-debian-linux-gnu...
> 2010/02/17 12:12:46| Process ID 20045
> 2010/02/17 12:12:46| With 8192 file descriptors available
> 2010/02/17 12:12:46| Using epoll for the IO loop
> 
> Google yielded a response where somebody else had a similar problem The
> recommendation was to file a bug report.
> 
> Now:
> (1) Is there a fix for this available somewhere?
> (2) This distro also features Squid3.
> 
> Any recommendations? Remove Squid 2.7 and install 2.6 or remove 2.7 and
> install Squid3?


And the develpers/support first reaction is ... "please try the latest
release and verify that it still exists". Especially if you found prior
evidence of people reporting it.
 that means 2.7.STABLE7

Amos

Re: [squid-users] assertion failed: forward.c:109

[Henrik Nordström]

tor 2010-02-18 klockan 00:41 +0200 skrev Thomas:
> Did I really post such a stupid question to receive such a sarcastic
> answer?

Was it? Quite a lot of bugs gets fixed in 1.5 years and no one keeps
track of them all. Memory of past bugs tends to fade after some months
at most, and as a result none of the developers investigates bug reports
unless reproduced in a reasonably recent version. And fact is that most
of the time when seeing problems with a release older than a year the
bug has already been fixed if there isn't an open bug report on it
already.

Anyway, the list of known fixed bugs is in the ChangeLog, and yes from
what I can tell yours is listed there, so please go and upgrade.

  http://www.squid-cache.org/Versions/v2/2.7/ChangeLog.txt

Regards
Henrik

Re: [squid-users] assertion failed: forward.c:109

[Amos Jeffries]

> -Original Message-
> From: Amos Jeffries 
> To: Squid Users 
> Subject: Re: [squid-users] assertion failed: forward.c:109
> Date: Thu, 18 Feb 2010 10:45:48 +1300
> 
> On Wed, 17 Feb 2010 13:07:25 +0200, Thomas 
> wrote:
>> Hi!
>> 
>> I recently installed Squid 2.7 Stable3 on a Ubuntu 8.10 Server (64-bit)
>> box. However, since about two weeks ago, the following error started
>> showing up (and it seems to appear more frequently now):
>> 
>> 2010/02/17 12:06:14| squidaio_queue_request: WARNING - Queue congestion
>> 2010/02/17 12:07:49| clientTryParseRequest: FD 258 (10.55.2.104:3183)
>> Invalid Request
>> 2010/02/17 12:12:26| parseHttpRequest: Unsupported method
>> 'ü¢Ÿº‚.¬×ëX;Wã—qNe±ôÞ…x®/rð`'
>> 2010/02/17 12:12:26| clientTryParseRequest: FD 262 (172.50.3.6:2072)
>> Invalid Request
>> 2010/02/17 12:12:43| assertion failed: forward.c:109:
>> "!EBIT_TEST(e->flags, ENTRY_FWD_HDR_WAIT)"
>> 2010/02/17 12:12:46| Starting Squid Cache version 2.7.STABLE3 for
>> amd64-debian-linux-gnu...
>> 2010/02/17 12:12:46| Process ID 20045
>> 2010/02/17 12:12:46| With 8192 file descriptors available
>> 2010/02/17 12:12:46| Using epoll for the IO loop
>> 
>> Google yielded a response where somebody else had a similar problem The
>> recommendation was to file a bug report.
>> 
>> Now:
>> (1) Is there a fix for this available somewhere?
>> (2) This distro also features Squid3.
>> 
>> Any recommendations? Remove Squid 2.7 and install 2.6 or remove 2.7 and
>> install Squid3?
> 
> 
> And the develpers/support first reaction is ... "please try the latest
> release and verify that it still exists". Especially if you found prior
> evidence of people reporting it.
>  that means 2.7.STABLE7
> 

On Thu, 18 Feb 2010 00:41:22 +0200, Thomas 
wrote:
> Did I really post such a stupid question to receive such a sarcastic
> answer?
> 

stupid? no.
sarcastic? I don't think so, but apologies if it came across that way.

lets try that again.

Please try 2.7.STABLE7. Simply because its the currently supported release
from the version series you are already using. The snapshot pre-STABLE8 may
be an even better test, with more bug fixes in it.
The google search result you found indicates that it is a known problem. I
believe it's resolved in some releases, though off the top of my head I'm
not certain if its in 2.7 already.

If the current 2.7 and snapshot does not solve it either, then will be the
time to try release from the 3.x series (or if you just want an excuse to
try the 3.x, feel free).

Amos

Re: [squid-users] Assertion failed in forward.cc

[Alex Rousskov]

On Wed, 2008-09-17 at 16:00 +0200, Dietmar Braun wrote:
> Hi,
> 
> we were using Squid 3.0 STABLE8, now STABLE9. In both, we are
> experiencing squid dying with the following debug message:
> 
> 2008/09/17 14:21:53| assertion failed: forward.cc:1209: "(fs->code == 
> HIER_DIRECT) == !fs->_peer"
> 2008/09/17 14:21:56| Squid is already running!  Process ID 11415
> 2008/09/17 14:21:59| Starting Squid Cache version 3.0.STABLE9 for 
> x86_64-unknown-linux-gnu...
> ...
> 
> Is that a known bug, or can we do something against that?

This is a known bug:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2391

I have not investigated it myself, but the recommendation in the bug
report is to remove the assertion as it is incorrect.

HTH,

Alex.

Re: [squid-users] Assertion failed in forward.cc

[Amos Jeffries]

Dietmar Braun wrote:

Hi,

Wednesday, September 17, 2008, 5:28:45 PM, you wrote:

This is a known bug:
http://www.squid-cache.org/bugs/show_bug.cgi?id=2391


Thank you for the quick reply.


I have not investigated it myself, but the recommendation in the bug
report is to remove the assertion as it is incorrect.


Does that mean I just should remove the line 1209 (assert(...)) in the
code and recompile?


Pretty much. I've just applied the patch to 3.0 codebase, so it will be 
out in the next snapshot, or the patch is listed at:

  http://www.squid-cache.org/Versions/v3/3.0/changesets/

Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE9

Re: [squid-users] assertion failed in HttpReply.c

[Henrik Nordstrom]

ons 2006-05-31 klockan 17:10 +0300 skrev Eugene:
> I've upgraded squid to stable14 yesterday and today it
> periodically dies with message in cache.log:
> 
> 2006/05/31 09:08:17| assertion failed: HttpReply.c:105: "rep"

Please get a stack trace and file a bug report.


  http://www.squid-cache.org/bugs/

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel

Re: [squid-users] assertion failed: client_side.c:4175

[Adrian Chadd]

On Tue, Sep 04, 2007, Tek Bahadur Limbu wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi All,
> 
> I recently upgraded from Squid-2.6.STABLE12 to Squid-2.6.STABLE15 on a 
> FreeBSD-6.1 amd64 machine. I am using the Diskd storage system.

The title says it all:

http://squidproxy.wordpress.com/2007/09/03/dont-upgrade-to-squid-26stable15-skip-straight-to-squid-26stable16/

:)




Adrian

> I seem be to getting the following error causing Squid to crash and restart 
> itself.
> 
> 2007/09/04 15:24:28| assertion failed: client_side.c:4175: "buf != NULL || 
> !conn->body.request"
> 2007/09/04 15:24:31| Starting Squid Cache version 2.6.STABLE15 for 
> amd64-unknown-freebsd6.1...
> 2007/09/04 15:24:31| Process ID 50809
> 2007/09/04 15:24:31| With 8192 file descriptors available
> 2007/09/04 15:24:31| Using kqueue for the IO loop
> 2007/09/04 15:24:31| DNS Socket created at 0.0.0.0, port 51857, FD 5
> 2007/09/04 15:24:31| Adding nameserver 127.0.0.1 from squid.conf
> 
> Is this problem related to Diskd? 
> 
> Thanking you...
> 
> 
> 
> 
> - -- 
> 
> With best regards and good wishes,
> 
> Yours sincerely,
> 
> Tek Bahadur Limbu
> 
> (TAG/TDG Group)
> Jwl Systems Department
> 
> Worldlink Communications Pvt. Ltd.
> 
> Jawalakhel, Nepal
> http://wlink.com.np/
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (FreeBSD)
> 
> iD8DBQFG3Ud9fpE0pz+xqQQRAlixAKDHmgU51EdkQan9KpPX3lyYRU7jqgCdFPHk
> 7g/TCRQoy42kWS49rRIo8Ss=
> =TIyw
> -END PGP SIGNATURE-

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level bandwidth-capped VPSes available in WA -

Re: [squid-users] assertion failed: client_side.c:4175

[Tek Bahadur Limbu]

Adrian Chadd wrote:

On Tue, Sep 04, 2007, Tek Bahadur Limbu wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi All,

I recently upgraded from Squid-2.6.STABLE12 to Squid-2.6.STABLE15 on a 
FreeBSD-6.1 amd64 machine. I am using the Diskd storage system.


The title says it all:

http://squidproxy.wordpress.com/2007/09/03/dont-upgrade-to-squid-26stable15-skip-straight-to-squid-26stable16/

:)



Hi Adrian,

Thanks for the correction. I guess I should downgrade to squid-2.6.STABLE14.

Thanking you...







Adrian


I seem be to getting the following error causing Squid to crash and restart 
itself.

2007/09/04 15:24:28| assertion failed: client_side.c:4175: "buf != NULL || 
!conn->body.request"
2007/09/04 15:24:31| Starting Squid Cache version 2.6.STABLE15 for 
amd64-unknown-freebsd6.1...
2007/09/04 15:24:31| Process ID 50809
2007/09/04 15:24:31| With 8192 file descriptors available
2007/09/04 15:24:31| Using kqueue for the IO loop
2007/09/04 15:24:31| DNS Socket created at 0.0.0.0, port 51857, FD 5
2007/09/04 15:24:31| Adding nameserver 127.0.0.1 from squid.conf

Is this problem related to Diskd? 


Thanking you...




- -- 


With best regards and good wishes,

Yours sincerely,

Tek Bahadur Limbu

(TAG/TDG Group)
Jwl Systems Department

Worldlink Communications Pvt. Ltd.

Jawalakhel, Nepal
http://wlink.com.np/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFG3Ud9fpE0pz+xqQQRAlixAKDHmgU51EdkQan9KpPX3lyYRU7jqgCdFPHk
7g/TCRQoy42kWS49rRIo8Ss=
=TIyw
-END PGP SIGNATURE-





--

With best regards and good wishes,

Yours sincerely,

Tek Bahadur Limbu

System Administrator

(TAG/TDG Group)
Jwl Systems Department

Worldlink Communications Pvt. Ltd.

Jawalakhel, Nepal

http://www.wlink.com.np

Re: [squid-users] assertion failed: client_side.c:4175

[Henrik Nordstrom]

On tis, 2007-09-04 at 18:49 +0545, Tek Bahadur Limbu wrote:
> Adrian Chadd wrote:
> > On Tue, Sep 04, 2007, Tek Bahadur Limbu wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> Hi All,
> >>
> >> I recently upgraded from Squid-2.6.STABLE12 to Squid-2.6.STABLE15 on a 
> >> FreeBSD-6.1 amd64 machine. I am using the Diskd storage system.
> > 
> > The title says it all:
> > 
> > http://squidproxy.wordpress.com/2007/09/03/dont-upgrade-to-squid-26stable15-skip-straight-to-squid-26stable16/
> > 
> > :)
> > 
> 
> Hi Adrian,
> 
> Thanks for the correction. I guess I should downgrade to squid-2.6.STABLE14.

2.6.STABLE16 is out.

Also there has been a patch available for this problem the whole week..
http://www.squid-cache.org/Versions/v2/2.6/changesets/11635.patch

Regards
Henrik


signature.asc
Description: This is a digitally signed message part

Re: [squid-users] assertion failed: client_side.c:4175

[Tek Bahadur Limbu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Henrik,

On Thu, 06 Sep 2007 01:42:12 +0200
Henrik Nordstrom <[EMAIL PROTECTED]> wrote:

> On tis, 2007-09-04 at 18:49 +0545, Tek Bahadur Limbu wrote:
> > Adrian Chadd wrote:
> > > On Tue, Sep 04, 2007, Tek Bahadur Limbu wrote:
> > >> -BEGIN PGP SIGNED MESSAGE-
> > >> Hash: SHA1
> > >>
> > >> Hi All,
> > >>
> > >> I recently upgraded from Squid-2.6.STABLE12 to Squid-2.6.STABLE15 on a 
> > >> FreeBSD-6.1 amd64 machine. I am using the Diskd storage system.
> > > 
> > > The title says it all:
> > > 
> > > http://squidproxy.wordpress.com/2007/09/03/dont-upgrade-to-squid-26stable15-skip-straight-to-squid-26stable16/
> > > 
> > > :)
> > > 
> > 
> > Hi Adrian,
> > 
> > Thanks for the correction. I guess I should downgrade to squid-2.6.STABLE14.
> 
> 2.6.STABLE16 is out.
> 
> Also there has been a patch available for this problem the whole week..
> http://www.squid-cache.org/Versions/v2/2.6/changesets/11635.patch

Thanks for the patch. I will apply the patch later today.


Thanking you...


> 
> Regards
> Henrik
> 


- -- 

With best regards and good wishes,

Yours sincerely,

Tek Bahadur Limbu

System Administrator 

(TAG/TDG Group)
Jwl Systems Department

Worldlink Communications Pvt. Ltd.

Jawalakhel, Nepal
http://wlink.com.np/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFG37XefpE0pz+xqQQRArz0AJ9h+2wWovG45CPF9gTB2KjJ0tZcAQCfTlBk
3/T3+WmsouERB/WXC+RT6NM=
=G5Tb
-END PGP SIGNATURE-

Re: [squid-users] assertion failed: client_side.c:4175

[Henrik Nordstrom]

On tor, 2007-09-06 at 13:55 +0545, Tek Bahadur Limbu wrote:

> > 2.6.STABLE16 is out.
> > 
> > Also there has been a patch available for this problem the whole week..
> > http://www.squid-cache.org/Versions/v2/2.6/changesets/11635.patch
> 
> Thanks for the patch. I will apply the patch later today.

The patch is included in 2.6.STABLE16.

Regards
Henrik


signature.asc
Description: This is a digitally signed message part

Re: [squid-users] assertion failed: client_side.c:4175

[Tek Bahadur Limbu]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Henrik,

On Thu, 06 Sep 2007 10:21:34 +0200
Henrik Nordstrom <[EMAIL PROTECTED]> wrote:

> On tor, 2007-09-06 at 13:55 +0545, Tek Bahadur Limbu wrote:
> 
> > > 2.6.STABLE16 is out.
> > > 
> > > Also there has been a patch available for this problem the whole week..
> > > http://www.squid-cache.org/Versions/v2/2.6/changesets/11635.patch
> > 
> > Thanks for the patch. I will apply the patch later today.
> 
> The patch is included in 2.6.STABLE16.

Sorry for the confusion:) I have already downloaded 2.6.STABLE16 and I am 
installing it right now!!

Thanking you..

> 
> Regards
> Henrik
> 


- -- 

With best regards and good wishes,

Yours sincerely,

Tek Bahadur Limbu

System Administrator 

(TAG/TDG Group)
Jwl Systems Department

Worldlink Communications Pvt. Ltd.

Jawalakhel, Nepal
http://wlink.com.np/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFG39rDfpE0pz+xqQQRAsloAKDDyOSRC0YneJr5ZBJM4mbcBnUlrwCgkwiJ
AhHyPwtfSkr9PiCLVC3oa+o=
=VKea
-END PGP SIGNATURE-

Re: [squid-users] "assertion failed" on exit

[Marc Elsen]

oleg-s wrote:
> 
> hello.
> is this a bug or just normal under some circumstances?
> -
> 2003/09/17 05:17:12| FD 7 Closing HTTP connection
> 2003/09/17 05:17:12| Shutting down...
> 2003/09/17 05:17:12| assertion failed: digest/auth_digest.c:551: 
> "memPoolInUseCount(digest_request_pool) == 0"
> 2003/09/17 05:17:12| assertion failed: digest/auth_digest.c:487: 
> "memPoolInUseCount(digest_user_pool) == 0"
> 2003/09/17 05:17:12| assertion failed: digest/auth_digest.c:240: 
> "memPoolInUseCount(digest_nonce_pool) == 0"
> 2003/09/17 05:17:12| Closing unlinkd pipe on FD 35
> 2003/09/17 05:17:12| storeDirWriteCleanLogs: Starting...
> 2003/09/17 05:17:14| 65536 entries written so far.
> 2003/09/17 05:17:14|131072 entries written so far.
> 2003/09/17 05:17:22|196608 entries written so far.
> 2003/09/17 05:17:25|   Finished.  Wrote 204811 entries.
> 2003/09/17 05:17:25|   Took 12.7 seconds (16066.7 entries/sec).
> CPU Usage: 636.840 seconds = 320.510 user + 316.330 sys
> Maximum Resident Size: 0 KB
> Page faults with physical i/o: 665
> Memory usage for squid via mallinfo():
> total space in arena:   63249 KB
> Ordinary blocks:63121 KB   2405 blks
> Small blocks:   0 KB  0 blks
> Holding blocks:   200 KB  1 blks
> Free Small blocks:  0 KB
> Free Ordinary blocks: 128 KB
> Total in use:   63321 KB 100%
> Total free:   128 KB 0%
> 2003/09/17 05:17:25| Open FD  37 squid -> diskd
> 2003/09/17 05:17:25| Squid Cache (Version 2.5.STABLE3): Exiting normally.
> ---
> thanks for answers.
> oleg

 All assertion messages are bug related.

 Have a go with the lastest STABLE4 release.

 M.


-- 

 'Love is truth without any future.
 (M.E. 1997)

Re: [squid-users] "assertion failed" on exit

[Henrik Nordstrom]

Looks like a minor bug.

Pleaser try upgrading to 2.5.STABLE4. If that does not help register a bug 
report.

Regards
Henrik


On Wed, 17 Sep 2003, oleg-s wrote:

> hello.
> is this a bug or just normal under some circumstances?
> -
> 2003/09/17 05:17:12| FD 7 Closing HTTP connection
> 2003/09/17 05:17:12| Shutting down...
> 2003/09/17 05:17:12| assertion failed: digest/auth_digest.c:551: 
> "memPoolInUseCount(digest_request_pool) == 0"
> 2003/09/17 05:17:12| assertion failed: digest/auth_digest.c:487: 
> "memPoolInUseCount(digest_user_pool) == 0"
> 2003/09/17 05:17:12| assertion failed: digest/auth_digest.c:240: 
> "memPoolInUseCount(digest_nonce_pool) == 0"
> 2003/09/17 05:17:12| Closing unlinkd pipe on FD 35
> 2003/09/17 05:17:12| storeDirWriteCleanLogs: Starting...
> 2003/09/17 05:17:14| 65536 entries written so far.
> 2003/09/17 05:17:14|131072 entries written so far.
> 2003/09/17 05:17:22|196608 entries written so far.
> 2003/09/17 05:17:25|   Finished.  Wrote 204811 entries.
> 2003/09/17 05:17:25|   Took 12.7 seconds (16066.7 entries/sec).
> CPU Usage: 636.840 seconds = 320.510 user + 316.330 sys
> Maximum Resident Size: 0 KB
> Page faults with physical i/o: 665
> Memory usage for squid via mallinfo():
> total space in arena:   63249 KB
> Ordinary blocks:63121 KB   2405 blks
> Small blocks:   0 KB  0 blks
> Holding blocks:   200 KB  1 blks
> Free Small blocks:  0 KB
> Free Ordinary blocks: 128 KB
> Total in use:   63321 KB 100%
> Total free:   128 KB 0%
> 2003/09/17 05:17:25| Open FD  37 squid -> diskd
> 2003/09/17 05:17:25| Squid Cache (Version 2.5.STABLE3): Exiting normally.
> ---
> thanks for answers.
> oleg
> 

Re: [squid-users] assertion failed: StatHist.c:93

[Henrik Nordstrom]

On Fri, 28 Nov 2003, Marc Remy wrote:

> This hapen wenn you don't have the "math.h" on your system (if you don't 
> have it on standart directoy, be sure that compiler look into this 
> directory, -I my_directory with gcc).
> The configure script just write "math.h: no", but didn't stop nor complain.
> To be honnest, it write so fast that I've seen it after solving the 
> problem...

Ah, explains why the problem is coming/going every now and then, and 
almost only on Solaris.. and why none of the developers have succeeded in 
ever reproducing the error.

Many thanks for finding this. Will try to add a warning to configure to 
warn about this potential problem.

If you please register a bug report to remind me.. a bit busy at the 
moment with other tasks.

Regards
Henrik

Re: [squid-users] Assertion failed in store_client.cc:430

[Henrik Nordstrom]

On fre, 2008-11-07 at 13:40 +0100, Dietmar Braun wrote:

> we are using Squid 3.0 STABLE9. Once a day, we get a
> 
> 2008/11/06 22:28:07| assertion failed: store_client.cc:430: 
> "STORE_DISK_CLIENT == getType()"
> 
> with a restart of Squid. Is this a known bug, can we do anything here?

File a bug report, preferably with a stack backtrace of the error.

Regards
Henrik

Re: [squid-users] assertion failed: HttpHdrRange.cc:606: "valid"

[Henrik Nordstrom]

On Sun, 2 Oct 2005, Ben Kinghorn wrote:


Squid: 3.0-PRE3-20040704


Over a year old developer snapshot release.


Current version for production use is

  2.5.STABLE11 (+ delay pools patch if using delay pools)

Squid-3.0 is still under development and not considered suitable for 
production use. But you are welcome to file a bug report if you can 
reproduce the error in a more recent Squid-3.0 snapshot release.


Regards
Henrik

Re: [squid-users] assertion failed: diskd/store_dir_diskd.c:868

[Mark Elsen]

>
> Hi another funny crash:
>
> Feb  1 20:37:43 wco-val kernel: pid 2923 (squid), uid 1004: exited on signal 6
> Feb  1 20:37:43 wco-val squid[2923]: assertion failed:
> diskd/store_dir_diskd.c:868: "rb->flags.need_to_validate"
>
>

 This is a fatal error, as you state,
 SQUID version ? Advising to use the latest STABLE release if , not done.

 M.

Re: [squid-users] assertion failed: diskd/store_dir_diskd.c:868

[H]

On Thursday 02 February 2006 05:07, you wrote:
> > Hi another funny crash:
> >
> > Feb  1 20:37:43 wco-val kernel: pid 2923 (squid), uid 1004: exited on
> > signal 6 Feb  1 20:37:43 wco-val squid[2923]: assertion failed:
> > diskd/store_dir_diskd.c:868: "rb->flags.need_to_validate"
>
>  This is a fatal error, as you state,
>  SQUID version ? Advising to use the latest STABLE release if , not done.
>

o sorry forgot to mention
any 12 and higher up to latest daily release 

H.







A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br

Re: [squid-users] assertion failed: diskd/store_dir_diskd.c:868

[Mark Elsen]

>
> o sorry forgot to mention
> any 12 and higher up to latest daily release
>
> H.
>


Make sure that none of your logfiles and or
swap.state  are  over 2Gig (?)

M.

Re: [squid-users] assertion failed: diskd/store_dir_diskd.c:868

[Edinilson J. Santos]

After migrate from Freebsd 4.8+Squid 2.5 Stable4 to Freebsd 6.0+Stable12 we 
are having the same problem here with DISKD (+- 45 minutos online and crash 
with the same error as described).
To bypass temporarily the problem, we are using UFS but with poor 
performance...

Edinilson
-
ATINET-Professional Web Hosting
Tel Voz: (0xx11) 4412-0876
http://www.atinet.com.br


- Original Message - 
From: "H" <[EMAIL PROTECTED]>
To: 
Sent: Wednesday, February 01, 2006 9:36 PM
Subject: [squid-users] assertion failed: diskd/store_dir_diskd.c:868



Hi another funny crash:

Feb  1 20:37:43 wco-val kernel: pid 2923 (squid), uid 1004: exited on signal 
6
Feb  1 20:37:43 wco-val squid[2923]: assertion failed:
diskd/store_dir_diskd.c:868: "rb->flags.need_to_validate"


what flags are that?


-- 


H.







A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada 
segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br

Re: [squid-users] assertion failed: diskd/store_dir_diskd.c:868

[H]

On Thursday 02 February 2006 09:33, Edinilson J. Santos wrote:
> After migrate from Freebsd 4.8+Squid 2.5 Stable4 to Freebsd 6.0+Stable12 we
> are having the same problem here with DISKD (+- 45 minutos online and crash
> with the same error as described).


Hi
are you sure that it is diskd.c:868

you could check again please?



-- 


H.





A mensagem foi scaneada pelo sistema de e-mail
automaticamente e pode ser considerada segura.
Service fornecido pelo Datacenter Matik
https://datacenter.matik.com.br

Re: [squid-users] assertion failed: diskd/store_dir_diskd.c:868

[H]

On Thursday 02 February 2006 05:23, Mark Elsen wrote:
> > o sorry forgot to mention
> > any 12 and higher up to latest daily release
> >
> > H.
>
> Make sure that none of your logfiles and or
> swap.state  are  over 2Gig (?)
>
\


this error appearently has to do with the swapfile age

I still had no time to check deeper but seems that here may be hidden "the 
problem" of other problems




-- 


H.





A mensagem foi scaneada pelo sistema de e-mail
automaticamente e pode ser considerada segura.
Service fornecido pelo Datacenter Matik
https://datacenter.matik.com.br

Re: [squid-users] assertion failed: diskd/store_dir_diskd.c:868

[Henrik Nordstrom]

On Wed, 1 Feb 2006, H wrote:


Hi another funny crash:

Feb  1 20:37:43 wco-val kernel: pid 2923 (squid), uid 1004: exited on signal 6
Feb  1 20:37:43 wco-val squid[2923]: assertion failed:
diskd/store_dir_diskd.c:868: "rb->flags.need_to_validate"


Internal error in Squid. File a bug report as per the instructions in the 
Squid FAQ on how to file bug reports.


Regards
Henrik

Re: [squid-users] assertion failed "mem->inmem_hi == 0"

[Wei Keong]

Hi,

I encounter the same error while testing icap to anti-virus-scan-server on
squid-2.5S4.

assertion failed: errorpage.c:292: "mem->inmem_hi == 0"

I notice that this error will only happen when a virus is found.

Is this a squid bug or problem with icap? Did you manage to resolve this
problem?

Thanks,
Wei Keong





> Mike Cudmore [EMAIL PROTECTED]
> Fri, 24 Jan 2003 12:31:06 +
>
> I am testing squid working with icap. I am using squid icap client patch
> (1.2.1) from source forge. When I test the squid I get the following
> error.
>
> 2003/01/23 15:04:35| assertion failed: errorpage.c:271: "mem->inmem_hi
> == 0"
>
> in the cache.log file.
>
> After this squid executes a normal startup sequence.
>
> This is regardless of url entered in the browser. (e.g.
> www.google.com)
> There are no entries in access.log nor anything other than normal
> startup sequence in cache.log
>
>
> When I disable ICAP in squid.conf the error does not occur.
>
> OS is linux redhat 8.0
> Squid is 2.5 stable 1
> ICAP server is Finjan's released version 7.0 of their icap enabled
> surfingate server,
>
> I have also put this issue on the squid-icapclient mailing list.
>
> Any one in the main squid arena able to offer any assistance?
>
> Regards
> Mike Cudmore
> GSI & Intranet Connectivity Team

Re: [squid-users] assertion failed "mem->inmem_hi == 0"

[Wei Keong]

Hi,

Managed to find this patch that seems to have solve the problem. Should we
include this in the squid-icap links?

http://sourceforge.net/tracker/index.php?func=detail&aid=651877&group_id=47737&atid=450621

Rgds,
Wei Keong


On Fri, 19 Sep 2003, Wei Keong wrote:

> Hi,
>
> I encounter the same error while testing icap to anti-virus-scan-server on
> squid-2.5S4.
>
> assertion failed: errorpage.c:292: "mem->inmem_hi == 0"
>
> I notice that this error will only happen when a virus is found.
>
> Is this a squid bug or problem with icap? Did you manage to resolve this
> problem?
>
> Thanks,
> Wei Keong
>
>
>
>
>
> > Mike Cudmore [EMAIL PROTECTED]
> > Fri, 24 Jan 2003 12:31:06 +
> >
> > I am testing squid working with icap. I am using squid icap client patch
> > (1.2.1) from source forge. When I test the squid I get the following
> > error.
> >
> > 2003/01/23 15:04:35| assertion failed: errorpage.c:271: "mem->inmem_hi
> > == 0"
> >
> > in the cache.log file.
> >
> > After this squid executes a normal startup sequence.
> >
> > This is regardless of url entered in the browser. (e.g.
> > www.google.com)
> > There are no entries in access.log nor anything other than normal
> > startup sequence in cache.log
> >
> >
> > When I disable ICAP in squid.conf the error does not occur.
> >
> > OS is linux redhat 8.0
> > Squid is 2.5 stable 1
> > ICAP server is Finjan's released version 7.0 of their icap enabled
> > surfingate server,
> >
> > I have also put this issue on the squid-icapclient mailing list.
> >
> > Any one in the main squid arena able to offer any assistance?
> >
> > Regards
> > Mike Cudmore
> > GSI & Intranet Connectivity Team
>
>
>
>

Re: [squid-users] assertion failed: refresh.c:163: "age >= 0"

[Marc Elsen]

Reinhold Seifert wrote:
> 
> Hi all,
> 
> we are running several squids 2.4STABLE1 on linux/i386 boxes for
> quite some time without any major problems. But --
> since about two weeks or so I see the following errors in cache.log:
> 
> 2003/01/24 13:25:21| ctx: enter level  0: 'http://www.dhl.com/art/logo.gif'
> 2003/01/24 13:25:21| assertion failed: refresh.c:163: "age >= 0"
> (squid restarts after this message)
> 
> Now, what is really strange is that (you guess it!) this problems *only*
> occurs with DHL web pages, ie. dhl.com, dhl.it, dhl.co.jp, dhl.es and
> so on (most of them are aliases of iproxy.dhl.com).
> 
> I wonder if anyone experiences the same problem (or can reproduce it).
> Also I am curious to know what the errors mean, and of course,
> how to get rid of these ;)

 Probably , in essence ,not related to dhl at all :-)
 Assertion failed is related to internal consistency checking within
 and or 'avoiding' unforeseen conditions.

 You may want to upgrade to the latest stable release 2.5S1.

 If the problem persists, then file a bug report.

 M.

> 
> Thanks,
> Reinhold

-- 

 'Time is a consequence of Matter thus
 General Relativity is a direct consequence of QM
 (M.E. Mar 2002)

Re: [squid-users] assertion failed: refresh.c:163: "age >= 0"

[Henrik Nordstrom]

Upgrading to a more recent Squid version might be a good idea. 
Squid-2.4 is end-of-life as far as the Squid developers is 
concerned..

Regards
Henrik


On Friday 24 January 2003 16.03, Reinhold Seifert wrote:
> Hi all,
>
> we are running several squids 2.4STABLE1 on linux/i386 boxes for
> quite some time without any major problems. But --
> since about two weeks or so I see the following errors in
> cache.log:
>
> 2003/01/24 13:25:21| ctx: enter level  0:
> 'http://www.dhl.com/art/logo.gif' 2003/01/24 13:25:21| assertion
> failed: refresh.c:163: "age >= 0" (squid restarts after this
> message)
>
> Now, what is really strange is that (you guess it!) this problems
> *only* occurs with DHL web pages, ie. dhl.com, dhl.it, dhl.co.jp,
> dhl.es and so on (most of them are aliases of iproxy.dhl.com).
>
> I wonder if anyone experiences the same problem (or can reproduce
> it). Also I am curious to know what the errors mean, and of course,
> how to get rid of these ;)
>
> Thanks,
> Reinhold

RE: [squid-users] assertion failed: HttpHeader.c:664: "strBuf(s)"

[Elsen Marc]

 
> Hi! 
> 
> We are running Squid Version 2.5.STABLE7-20050124, and we 
> begun experiencing 
> squid crashes, apparently due to the following error, found 
> in cache.log: 
> 
> 2005/03/16 08:36:44| WARNING: found whitespace in HTTP header 
> name {Cache 
> Control: no-cache} 
> 2005/03/16 08:36:44| ctx: exit level  0 
> 2005/03/16 08:36:44| WARNING: found whitespace in HTTP header 
> name {Cache 
> Control: no-cache} 
> 2005/03/16 08:36:44| assertion failed: HttpHeader.c:664: "strBuf(s)" 
> 
> We´ve searched the Bugzilla database, and there is a patch 
> for it, under Bug 
> #1207. 
> 
> As the Bugzilla database doesn´t state the Stable version to 
> with the patch 
> applies (or, at least, I didn´t find it), I would like to 
> know if this patch 
> applies to the version that we are running. 
> 
> Even if it does is it better to upgrade to Stable9? 
> 
> 


 It's probably better, to use Stable9, from starters if possible.
 Also because of re-iteraded corrections on header parsing and relaxing
 certain problem conditions (again).

 M.

Re: [squid-users] assertion failed: HttpHeader.c:664: "strBuf(s)"

[Henrik Nordstrom]

On Wed, 16 Mar 2005, zottmann wrote:
As the Bugzilla database doesn´t state the Stable version to with the patch
applies (or, at least, I didn´t find it), I would like to know if this patch
applies to the version that we are running.
Patches in bugzilla applies to the Squid sources at the time the patch was 
published in bugzilla, not a specific STABLE release.

But as you did indicate you are running 2.5.STABLE7-20050124 then I can 
tell you for sure that the version you are running is plauged by the 
problem this patch-for-a-patch in bugzilla corrects. I don't remember 
exacly when the problem was introduced but it was some weeks before the 
above date.

Even if it does is it better to upgrade to Stable9?
Keeping current is always recommended, especially so if you have trouble 
with the version you use today, and certainly so if you are unsure about 
the patch status of the version you use today.

Regards
Henrik

Re: [squid-users] assertion failed: pinger.c:187: "icmp_pktsize <= MAX_PKT_SZ"

[Henrik Nordstrom]

On Thu, 20 Nov 2003, Web server manager wrote:

> assertion failed: pinger.c:187: "icmp_pktsize <= MAX_PKT_SZ"
> 
> (and then terminating).
> 
> That's both good and bad - it implies that overlong response data has been 
> trapped rather than leaving the potential for exploitable buffer overflows,
> but leaves Squid without pinger running (it doesn't seem to be restarted
> automatically - though that could also be bad if it was happening
> continually).

No, this assertion is on the packet pinger is about to send.

Please file a bug report for this issue.

> Also, if pinger terminates, what happens to the data based on pinger's 
> measurements? Will Squid ignore old and potentially outdated RTT data, or 
> continue using it (not realising that it's no longer being maintained)?

Good question. I think it will continue using the old data until expired, 
maybe forever.

Regards
Henrik

Re: [squid-users] assertion failed: store_swapout.cc:317: "mem->swapout.sio == self"

[Adrian Chadd]

Does Squid-2.7.STABLE5 exhibit this issue?



Adrian


2008/11/28 Marcel Grandemange <[EMAIL PROTECTED]>:
> Looks like squid broke itself again.
> If anybody could advise me as to what's happening here it would be great.
>
> Im thinking the move to v3 has been disasterous so far.
>
> Every time is now use our main proxy the following happens..
>
> 2008/11/29 03:10:19|   Validated 1285147 Entries
> 2008/11/29 03:10:19|   store_swap_size = 25682924
> 2008/11/29 03:10:19| storeLateRelease: released 0 objects
> 2008/11/29 03:11:08| assertion failed: store_swapout.cc:317:
> "mem->swapout.sio == self"
> 2008/11/29 03:11:17| Starting Squid Cache version 3.0.STABLE9 for
> amd64-portbld-freebsd7.0...
> 2008/11/29 03:11:17| Process ID 32313
> 2008/11/29 03:11:17| With 11072 file descriptors available
> 2008/11/29 03:11:17| DNS Socket created at 0.0.0.0, port 63464, FD 7
> 2008/11/29 03:11:17| Adding nameserver 127.0.0.1 from squid.conf
> 2008/11/29 03:11:17| Adding nameserver 192.168.12.2 from squid.conf
> 2008/11/29 03:11:17| Adding nameserver 192.168.12.3 from squid.conf
> 2008/11/29 03:11:17| Unlinkd pipe opened on FD 12
> 2008/11/29 03:11:17| Swap maxSize 71925760 KB, estimated 4795050 objects
> 2008/11/29 03:11:17| Target number of buckets: 239752
> 2008/11/29 03:11:17| Using 262144 Store buckets
> 2008/11/29 03:11:17| Max Mem  size: 131072 KB
> 2008/11/29 03:11:17| Max Swap size: 71925760 KB
> 2008/11/29 03:11:22| Version 1 of swap file without LFS support detected...
> 2008/11/29 03:11:22| Rebuilding storage in /mnt/cache1 (DIRTY)
> 2008/11/29 03:11:22| Version 1 of swap file without LFS support detected...
> 2008/11/29 03:11:22| Rebuilding storage in /mnt/cache2 (DIRTY)
> 2008/11/29 03:11:22| Version 1 of swap file without LFS support detected...
> 2008/11/29 03:11:22| Rebuilding storage in /usr/local/squid/cache (DIRTY)
> 2008/11/29 03:11:22| Using Round Robin store dir selection
> 2008/11/29 03:11:22| Set Current Directory to /usr/local/squid/cache
> 2008/11/29 03:11:23| Loaded Icons.
> 2008/11/29 03:11:23| Accepting  HTTP connections at 192.168.12.1, port 3128,
> FD 18.
> 2008/11/29 03:11:23| Accepting  HTTP connections at 127.0.0.1, port 8080, FD
> 19.
> 2008/11/29 03:11:23| Accepting transparently proxied HTTP connections at
> 127.0.0.1, port 3128, FD 20.
> 2008/11/29 03:11:23| HTCP Disabled.
> 2008/11/29 03:11:23| Accepting SNMP messages on port 3401, FD 21.
> 2008/11/29 03:11:23| Configuring Parent 192.168.12.2/3128/3130
> 2008/11/29 03:11:23| Ready to serve requests.
> 2008/11/29 03:11:23| Store rebuilding is 3.48% complete
> 2008/11/29 03:11:28| Done reading /mnt/cache1 swaplog (117800 entries)
> 2008/11/29 03:11:28| Done reading /mnt/cache2 swaplog (117807 entries)
>
>
> It keeps crashing when you visit pages and reloading.. Input?
> Stable10 had other issues that prevents me from using it.
>
>

Re: [squid-users] assertion failed: store_swapout.cc:317: "mem->swapout.sio == self"

[Henrik Nordstrom]

File a bug report, preferably with a stack backtrace.

Regards
Henrik

lör 2008-11-29 klockan 03:24 +0200 skrev Marcel Grandemange:
> Looks like squid broke itself again.
> If anybody could advise me as to what's happening here it would be great.
> 
> Im thinking the move to v3 has been disasterous so far.
> 
> Every time is now use our main proxy the following happens..
> 
> 2008/11/29 03:10:19|   Validated 1285147 Entries
> 2008/11/29 03:10:19|   store_swap_size = 25682924
> 2008/11/29 03:10:19| storeLateRelease: released 0 objects
> 2008/11/29 03:11:08| assertion failed: store_swapout.cc:317:
> "mem->swapout.sio == self"
> 2008/11/29 03:11:17| Starting Squid Cache version 3.0.STABLE9 for
> amd64-portbld-freebsd7.0...
> 2008/11/29 03:11:17| Process ID 32313
> 2008/11/29 03:11:17| With 11072 file descriptors available
> 2008/11/29 03:11:17| DNS Socket created at 0.0.0.0, port 63464, FD 7
> 2008/11/29 03:11:17| Adding nameserver 127.0.0.1 from squid.conf
> 2008/11/29 03:11:17| Adding nameserver 192.168.12.2 from squid.conf
> 2008/11/29 03:11:17| Adding nameserver 192.168.12.3 from squid.conf
> 2008/11/29 03:11:17| Unlinkd pipe opened on FD 12
> 2008/11/29 03:11:17| Swap maxSize 71925760 KB, estimated 4795050 objects
> 2008/11/29 03:11:17| Target number of buckets: 239752
> 2008/11/29 03:11:17| Using 262144 Store buckets
> 2008/11/29 03:11:17| Max Mem  size: 131072 KB
> 2008/11/29 03:11:17| Max Swap size: 71925760 KB
> 2008/11/29 03:11:22| Version 1 of swap file without LFS support detected...
> 2008/11/29 03:11:22| Rebuilding storage in /mnt/cache1 (DIRTY)
> 2008/11/29 03:11:22| Version 1 of swap file without LFS support detected...
> 2008/11/29 03:11:22| Rebuilding storage in /mnt/cache2 (DIRTY)
> 2008/11/29 03:11:22| Version 1 of swap file without LFS support detected...
> 2008/11/29 03:11:22| Rebuilding storage in /usr/local/squid/cache (DIRTY)
> 2008/11/29 03:11:22| Using Round Robin store dir selection
> 2008/11/29 03:11:22| Set Current Directory to /usr/local/squid/cache
> 2008/11/29 03:11:23| Loaded Icons.
> 2008/11/29 03:11:23| Accepting  HTTP connections at 192.168.12.1, port 3128,
> FD 18.
> 2008/11/29 03:11:23| Accepting  HTTP connections at 127.0.0.1, port 8080, FD
> 19.
> 2008/11/29 03:11:23| Accepting transparently proxied HTTP connections at
> 127.0.0.1, port 3128, FD 20.
> 2008/11/29 03:11:23| HTCP Disabled.
> 2008/11/29 03:11:23| Accepting SNMP messages on port 3401, FD 21.
> 2008/11/29 03:11:23| Configuring Parent 192.168.12.2/3128/3130
> 2008/11/29 03:11:23| Ready to serve requests.
> 2008/11/29 03:11:23| Store rebuilding is 3.48% complete
> 2008/11/29 03:11:28| Done reading /mnt/cache1 swaplog (117800 entries)
> 2008/11/29 03:11:28| Done reading /mnt/cache2 swaplog (117807 entries)
> 
> 
> It keeps crashing when you visit pages and reloading.. Input?
> Stable10 had other issues that prevents me from using it.


signature.asc
Description: Detta är en digitalt signerad meddelandedel

Re: [squid-users] assertion failed: Server.cc:244: "r->body_pipe != NULL"

[Amos Jeffries]

On 30/01/2013 5:24 a.m., John Hay wrote:

Hi Guys,

I have been seeing this pretty often lately, with both 3.2.5 and 3.2.6.
I'm using FreeBSD 8.x in 64 bit mode and also IPv6.

The message in cache.log is:

2013/01/29 17:23:39 kid1| assertion failed: Server.cc:244: "r->body_pipe != 
NULL"
2013/01/29 17:23:42 kid1| Starting Squid Cache version 3.2.6 for 
amd64-portbld-freebsd8.2...

A backtrace with gdb looks like this:

###
proxy# gdb work/squid-3.2.6/src/squid /var/squid/cache/squid.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Core was generated by `squid'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /usr/lib/libgssapi.so.10...done.
Loaded symbols for /usr/lib/libgssapi.so.10
Reading symbols from /usr/lib/libheimntlm.so.10...done.
Loaded symbols for /usr/lib/libheimntlm.so.10
Reading symbols from /usr/lib/libkrb5.so.10...done.
Loaded symbols for /usr/lib/libkrb5.so.10
Reading symbols from /usr/lib/libhx509.so.10...done.
Loaded symbols for /usr/lib/libhx509.so.10
Reading symbols from /usr/lib/libcom_err.so.5...done.
Loaded symbols for /usr/lib/libcom_err.so.5
Reading symbols from /lib/libcrypto.so.6...done.
Loaded symbols for /lib/libcrypto.so.6
Reading symbols from /usr/lib/libasn1.so.10...done.
Loaded symbols for /usr/lib/libasn1.so.10
Reading symbols from /usr/lib/libroken.so.10...done.
Loaded symbols for /usr/lib/libroken.so.10
Reading symbols from /lib/libcrypt.so.5...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000801d6dfcc in kill () from /lib/libc.so.7
[New Thread 8020041c0 (LWP 102238)]
(gdb) bt
#0  0x000801d6dfcc in kill () from /lib/libc.so.7
#1  0x000801d6cdcb in abort () from /lib/libc.so.7
#2  0x005398dd in xassert (msg=0x792152 "r->body_pipe != NULL",
 file=0x791dc7 "Server.cc", line=244) at debug.cc:567
#3  0x00621d1f in ServerStateData::startRequestBodyFlow (
 this=0x8042a1058) at Server.cc:244
#4  0x0056c08b in FtpStateData::readStor (this=0x8042a1058)
 at ftp.cc:3077
#5  0x0056c425 in ftpReadStor (ftpState=0x8042a1058) at ftp.cc:3068
#6  0x005645f7 in FtpStateData::handleControlReply (this=0x8042a1058)
 at ftp.cc:1861
#7  0x00564d73 in FtpStateData::ftpReadControlReply (this=0x8042a1058,
 io=@0x80482db48) at ftp.cc:1810
#8  0x005759aa in CommCbMemFunT::doDial (
 this=0x80482db30) at CommCalls.h:198
#9  0x00575dbc in JobDialer::dial (this=0x80482db30,
 call=@0x80482db00) at AsyncJobCalls.h:175
#10 0x00575fdd in AsyncCallT 
>::fire (this=0x80482db00) at AsyncCall.h:142
#11 0x006ab5a4 in AsyncCall::make (this=0x80482db00) at AsyncCall.cc:36
#12 0x006af98c in AsyncCallQueue::fireNext (this=0x802018300)
 at AsyncCallQueue.cc:54
#13 0x006afaef in AsyncCallQueue::fire (this=0x802018300)
---Type  to continue, or q  to quit---
#

It looks a lot like bug 3498 in bugzilla:
http://bugs.squid-cache.org/show_bug.cgi?id=3498

Any ideas?


Yes it does appear to be that bug.
We don't have a fix for it yet. Any assitance you canprovide towards 
finding one would be helpful.



Amos

Re: [squid-users] assertion failed: Server.cc:244: "r->body_pipe != NULL"

[John Hay]

On Wed, Jan 30, 2013 at 06:41:07PM +1300, Amos Jeffries wrote:
> On 30/01/2013 5:24 a.m., John Hay wrote:
> >Hi Guys,
> >
> >I have been seeing this pretty often lately, with both 3.2.5 and 3.2.6.
> >I'm using FreeBSD 8.x in 64 bit mode and also IPv6.
> >
> >The message in cache.log is:
> >
> >2013/01/29 17:23:39 kid1| assertion failed: Server.cc:244: "r->body_pipe 
> >!= NULL"
> >2013/01/29 17:23:42 kid1| Starting Squid Cache version 3.2.6 for 
> >amd64-portbld-freebsd8.2...
...
> >
> >It looks a lot like bug 3498 in bugzilla:
> >http://bugs.squid-cache.org/show_bug.cgi?id=3498
> >
> >Any ideas?
> 
> Yes it does appear to be that bug.
> We don't have a fix for it yet. Any assitance you canprovide towards 
> finding one would be helpful.

I have added a print of *r and ctrl to the bug report. If more is needed,
please ask.

All the asserts that I have checked seems to be the same user and site
and the same files. The user does get and put many others on the same
site without a problem though. Looking on the ftp site, the failed
files do exist, but they are zero in length.

John
-- 
John Hay -- j...@meraka.csir.co.za / j...@freebsd.org

Re: [squid-users] assertion failed: Server.cc:245: "r->body_pipe != NULL"

[Alex Rousskov]

On 12/18/2013 09:07 AM, hdk...@hdkutz.de wrote:
> Hello List,
> I have a Problem on a Centos 6.4 64 Bit System running RPM Package
> squid-3.3.11-1.el6.x86_64.rpm

> Any hints or tips on 
> 
> assertion failed: Server.cc:245: "r->body_pipe != NULL"
> 
> ?

Please see http://bugs.squid-cache.org/show_bug.cgi?id=3498

You may want to post your stack trace there to confirm that your case is
similar, but I am not aware of anybody trying to fix that [FTP] bug
right now.

Alex.

Re: [squid-users] assertion failed: Server.cc:245: "r->body_pipe != NULL"

[hdkutz]

On Wed, Dec 18, 2013 at 11:03:13AM -0700, Alex Rousskov wrote:
> On 12/18/2013 09:07 AM, hdk...@hdkutz.de wrote:
> > Hello List,
> > I have a Problem on a Centos 6.4 64 Bit System running RPM Package
> > squid-3.3.11-1.el6.x86_64.rpm
> 
> > Any hints or tips on 
> > 
> > assertion failed: Server.cc:245: "r->body_pipe != NULL"
> > 
> > ?
> 
> Please see http://bugs.squid-cache.org/show_bug.cgi?id=3498
> 
> You may want to post your stack trace there to confirm that your case is
> similar, but I am not aware of anybody trying to fix that [FTP] bug
> right now.
> 
> Alex.
Hello Alex,
it seems to be the FTP Problem.
Here's a Stacktrace of squid during abort:

...
epoll_wait(6, {{EPOLLIN, {u32=432, u64=14609669202550718896}}, {EPOLLIN,
{u32=1256, u64=14609669202550719720}}}, 4096, 220) = 2
read(432, "150 Ok to send data.\r\n", 4096) = 22
epoll_ctl(6, EPOLL_CTL_DEL, 1256, {0, {u32=1256, u64=9886854727860225256}}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
write(5, "2013/12/19 10:06:13 kid1| assert"..., 82) = 82
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(11315, 11315, SIGABRT)   = 0
--- SIGABRT (Aborted) @ 0 (0) ---


Anything I can do to avoid the situation?
E.g. stop using ftp on my squid?


Cheers,
ku
-- 
Luke Skywalker:
Your overconfidence is your weakness.
Emperor Palpatine:
Your faith in your friends is yours.

Re: [squid-users] assertion failed: Server.cc:245: "r->body_pipe != NULL"

[Alex Rousskov]

On 12/19/2013 02:12 AM, hdk...@hdkutz.de wrote:
> On Wed, Dec 18, 2013 at 11:03:13AM -0700, Alex Rousskov wrote:
>> On 12/18/2013 09:07 AM, hdk...@hdkutz.de wrote:
>>> I have a Problem on a Centos 6.4 64 Bit System running RPM Package
>>> squid-3.3.11-1.el6.x86_64.rpm
>>
>>> Any hints or tips on 
>>> assertion failed: Server.cc:245: "r->body_pipe != NULL"
>>> ?


>> Please see http://bugs.squid-cache.org/show_bug.cgi?id=3498


> Anything I can do to avoid the situation?


FYI: A patch fixing this bug is now available. Please see the bug report
referenced above for details.


HTH,

Alex.

Re: [squid-users] assertion failed: store_swapout.cc:315: "mem->swapout.sio == self

[Eliezer Croitoru]

Hey,

couple questions:
- what are the machine specs?
- why are you using so many ufs cache dirs? is  there a reason?

Mainly this squid version is old and I suspect it's not supported anymore.
64 doubles 5.1 is above 240GB of cache which requires lots of memory.

Eliezer

On 05/03/2014 01:39 AM, viral shah wrote:

Hello,

I am running squid as http caching server, after running for few days
our squid server will stop responding to client requests.

When this occurs, I see below errors in cache.log.

Re: [squid-users] assertion failed: store_swapout.cc:315: "mem->swapout.sio == self

[viral shah]

Hi Eliezer,

Thanks for your response, please find the answers below.

what are the machine specs?
Machine on which Squid is running, is VM having 2 cores and 8 GB of memory.

why are you using so many ufs cache dirs? is  there a reason?
 Yes, our purpose is to cache more than 50M json objects.
 Tried running with single cache directory. that didn't work,
after 10-15 days Squid will stop responding with below error in
cahce.log.
"assertion failed: filemap.cc:76: "fm->max_n_files <= (1 << 24)"
I came across work around for the above issue on internet, that
mentioned having multiple cache directories.


Viral



On Sat, May 3, 2014 at 11:01 AM, Eliezer Croitoru  wrote:
> Hey,
>
> couple questions:
> - what are the machine specs?
> - why are you using so many ufs cache dirs? is  there a reason?
>
> Mainly this squid version is old and I suspect it's not supported anymore.
> 64 doubles 5.1 is above 240GB of cache which requires lots of memory.
>
> Eliezer
>
>
> On 05/03/2014 01:39 AM, viral shah wrote:
>>
>> Hello,
>>
>> I am running squid as http caching server, after running for few days
>> our squid server will stop responding to client requests.
>>
>> When this occurs, I see below errors in cache.log.
>
>

Re: [squid-users] assertion failed: store_swapout.cc:315: "mem->swapout.sio == self

[Eliezer Croitoru]

Well it happens that 8GB of memory will not be enough for 240GB of ufs 
disk cache as far as I can tell.

Lets try to fix it one step at a time.
Since you are getting into a position which squid get's stuck we can go 
from step A to B and then to C.


First decrease the number of ufs directories to something like 1...
The cache_dir can handle more then what some can imagine.
What is the cache_dir number of objects?
You can use the cache_mgr interface to get some statistics on the cache_dir.
It's version 3.1.20 so basically you should be able to access it using 
"squidclient mgr:menu"

I do not remember the exact name but it has something about the cache_dir.
After you will have one cache_dir which fits your number of files in a 
form of for example 64 top directories and 256 upper directories you 
might see something else.
note that 50M (million right?)json objects are huge but you might have a 
limit from the INODE limit of the FS way before squid limits.


The machine basically doesn't meet the basic specs to store 50Million files.

Eliezer


On 05/04/2014 08:27 PM, viral shah wrote:

Hi Eliezer,

Thanks for your response, please find the answers below.

what are the machine specs?
 Machine on which Squid is running, is VM having 2 cores and 8 GB of memory.

why are you using so many ufs cache dirs? is  there a reason?
  Yes, our purpose is to cache more than 50M json objects.
  Tried running with single cache directory. that didn't work,
after 10-15 days Squid will stop responding with below error in
cahce.log.
 "assertion failed: filemap.cc:76: "fm->max_n_files <= (1 << 24)"
 I came across work around for the above issue on internet, that
mentioned having multiple cache directories.


Viral



On Sat, May 3, 2014 at 11:01 AM, Eliezer Croitoru  wrote:

Hey,

couple questions:
- what are the machine specs?
- why are you using so many ufs cache dirs? is  there a reason?

Mainly this squid version is old and I suspect it's not supported anymore.
64 doubles 5.1 is above 240GB of cache which requires lots of memory.

Eliezer


On 05/03/2014 01:39 AM, viral shah wrote:


Hello,

I am running squid as http caching server, after running for few days
our squid server will stop responding to client requests.

When this occurs, I see below errors in cache.log.

Re: [squid-users] assertion failed: client_side.cc:1515: "connIsUsable(http->getConn())"

[Amos Jeffries]

On 22/05/2014 1:44 p.m., Dan Charlesworth wrote:
> We were just stress testing a forward proxy of ours, and suddenly received 
> this error which made squid crash pretty hard, apparently.
> 
> 2014/05/22 11:38:13 kid1| assertion failed: client_side.cc:1515: 
> "connIsUsable(http->getConn())"
> 2014/05/22 11:38:18 kid1| Set Current Directory to /var/spool/squid
> 2014/05/22 11:38:18 kid1| Starting Squid Cache version 3.4.4 for 
> x86_64-redhat-linux-gnu…
> 
> I couldn’t turn up anything by Googling. Anyone have any idea what went wrong?

http://bugs.squid-cache.org/show_bug.cgi?id=3930

Amos

Re: [squid-users] assertion failed: client_side.cc:1515: "connIsUsable(http->getConn())"

[Eliezer Croitoru]

Hey Dan,

What is the "squid -v" output?
"uname -a"
squid.conf content?
Did you had the chance to look at squid cache manager interface?
What is the size of the stress test?

the basic idea is that A connection should be usable for squid usage but 
it is not from unknown reason.

Once we have more details we can try to think one step forward.

Eliezer

On 05/22/2014 04:44 AM, Dan Charlesworth wrote:

We were just stress testing a forward proxy of ours, and suddenly received this 
error which made squid crash pretty hard, apparently.

2014/05/22 11:38:13 kid1| assertion failed: client_side.cc:1515: 
"connIsUsable(http->getConn())"
2014/05/22 11:38:18 kid1| Set Current Directory to /var/spool/squid
2014/05/22 11:38:18 kid1| Starting Squid Cache version 3.4.4 for 
x86_64-redhat-linux-gnu…

I couldn’t turn up anything by Googling. Anyone have any idea what went wrong?

Dan

Re: [squid-users] assertion failed: cbdata.cc:464: "c->locks > 0

[Amos Jeffries]

On 30/07/2014 10:44 p.m., Labusch, Christian (regio iT) wrote:
> Hello all,
> 
> i have a little Problem with the "new"  Directive "client_delay_pools". Our 
> old Config with the normal delay_classes works fine. But we need additional a 
> Upload-Limit.
> 
> Testmachine with very simple standard config:
> 
> - OS: Linux debian 3.2.0-4-486 #1 Debian 3.2.60-1+deb7u1 i686 GNU/Linux
> - Squid Cache: Version 3.4.6. (configure options:  '--enable-delay-pools')
> 
> Squid.conf (Limitation 1 Mbit/s):
> 
> client_delay_pools 1
> client_delay_initial_bucket_level 100
> client_delay_access 1 allow localnet
> client_delay_access 1 deny all
> client_delay_parameters 1 128000 128000
> 
> To start the squid-Daemon brings  the following error:
> 
> Cache.log:
> 
> 2014/07/30 10:33:02 kid1| assertion failed: cbdata.cc:464: "c->locks > 0"



> Do you have any ideas?

http://bugs.squid-cache.org/show_bug.cgi?id=3696

We require a stack trace to identify the cause of this one. If you can
obtain one from 3.4.6 (or better a current 3.HEAD tarball) that would be
very helpful. Please ensure that it actually has the function names
rather than hex numbers and add to the bug report along with the "squid
-v" output.

Amos

Re: [squid-users] assertion failed: cbdata.cc:464: "c->locks > 0

[Fernando Lozano]

Hi Amos,
> On 30/07/2014 10:44 p.m., Labusch, Christian (regio iT) wrote:
>> - OS: Linux debian 3.2.0-4-486 #1 Debian 3.2.60-1+deb7u1 i686 GNU/Linux
>> - Squid Cache: Version 3.4.6. (configure options:  '--enable-delay-pools')
>>
>> Squid.conf (Limitation 1 Mbit/s):
>>
>> client_delay_pools 1
>> client_delay_initial_bucket_level 100
>> client_delay_access 1 allow localnet
>> client_delay_access 1 deny all
>> client_delay_parameters 1 128000 128000
>>
>> To start the squid-Daemon brings  the following error:
>>
>> Cache.log:
>>
>> 2014/07/30 10:33:02 kid1| assertion failed: cbdata.cc:464: "c->locks > 0"
> http://bugs.squid-cache.org/show_bug.cgi?id=3696

Just for the record, I got the same error (same assert) when I tried to
enable client_delay_pools. But using CentOS 6.4 ou a 64-bit Xeon Dell
server and squid 3.4.6 installed from Eliezer RPMs.

Very different machine and OS, so it's not something specific to
Christian setup.

I took a look at the bug and comments give the impression that people
thought it was reladted to the older delay_pools (not client_delay) when
they reported "works fine for me".

The bug state could be moved to something other than UNCONFIRMED. And I
have to remember how to get debug symbols for the RPM and generate a
stack trace. ;-)


[]s, Fernando Lozano

Re: [squid-users] assertion failed: cbdata.cc:402: "c->locks > 0"

[Henrik Nordstrom]

On Mon, 17 Jan 2005, H Matik wrote:
cbdata.cc:402: "c->locks > 0"
on FreeBSD 5.2.1Rand 5.3R from squid-3.0-PRE3-20040116
Squid compiles fine with any compile options and starts as well also, soon the
first request comes in it exites with this error.
Please file a bug report as per the instructions in the Squid FAQ
  Squid FAQ 11.19 Sending in Squid bug reports
  http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.19>
Regards
Henrik

Re: [squid-users] assertion failed: ClientBody.cc:44: "conn->body_size_left > 0"

[Mark Elsen]

 > Hi,
>
> I'm new to this list, so first, hello there!
>
> I'm running with squid 3.0-PRE3-20060313 on a x86_64 arch and I often
> see the following message in my syslog:
>
> squid[11404]: assertion failed: ClientBody.cc:44: "conn-
>  >body_size_left > 0"
> squid[10133]: Squid Parent: child process 11404 exited due to signal 6
> squid[10133]: Squid Parent: child process 11508 started
>
> I don't know how bad is it, but I guess it's a bug isn't it?
>

  - Very bad, bug yes.
  - You are using software not ready for production use.

 M.

Re: [squid-users] assertion failed: diskd/store_io_diskd.c:369: "!diskdstate->flags.close_request"

[Henrik Nordstrom]

On Wed, 21 Jul 2004, Gaylord Van Brocklin wrote:

> Squid 2.5STABLE5 on a Dual Xeon 2.8 w/ 2 gigs of memory running FreeBSD 
> 4.10-STABLE.
> 
> I've been running for a few weeks since a clean rebuild without issues, 
> but now saw about three of these today:
> 
>  From cache.log:
> 2004/07/21 10:11:14| assertion failed: diskd/store_io_diskd.c:369: 
> "!diskdstate->flags.close_request"
> 
>  From OS /var/log/messages:
> Jul 21 10:12:48 squid /kernel: pid 95842 (squid), uid 100: exited on 
> signal 6 (core dumped)
> Jul 21 10:12:48 squid squid[95839]: Squid Parent: child process 95842 
> exited due to signal 6
> 
> I have a core dump to trace if required... but any ideas?

See the Squid FAQ on how to report bugs.

Regards
Henrik

Re: [squid-users] assertion failed: diskd/store_io_diskd.c:384: "!diskdstate->flags.close_request"

[Adrian Chadd]

On Thu, Feb 08, 2007, admin wrote:
> Our newly installed moderately loaded Squid 2.6+diskd has restarted
> itself twice for the last day with the same error message in cache.log:

Hiya,

Please submit a bug report through bugzilla.
In the meanwhile - FreeBSD's libthr should work fine with aufs; give that a 
whirl
until the diskd stuff can be sorted out.



Adrian

> 
> assertion failed: diskd/store_io_diskd.c:384:
> "!diskdstate->flags.close_request"
> 
> OS FreeBSD 6.2
> Squid 2.6.STABLE9 + diskd'd cache_dir
> Some random bits from cachemgr's output:
> 
>   Number of clients accessing cache:  472
>   Average HTTP requests per minute since start:   6780.2
>   Requests given to unlinkd:  14321
> DISKD Stats:
> sent_count: 1229469
> recv_count: 1229457
> max_away: 73
> max_shmuse: 73
> open_fail_queue_len: 0
> block_queue_len: 146199773
> 
>   OPS   SUCCESSFAIL
>open 97702 948512848
>  create 79079 79079   0
>   close173899173893   0
>  unlink171021 15639  155382
>read203135200284   0
>   write504633504629   0
> 
> 
> Looks as though diskd's constantly failing to unlink files as the
> counter's growing every second. Opens fail less frequently as one can see.
> 
> 
> Any suggestions? If any further info is needed, please ask.

-- 
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $25/pm entry-level bandwidth-capped VPSes available in WA -

Re: [squid-users] Assertion failed error causing worker process to restart

[FredB]

> Objet: [squid-users] Assertion failed error causing worker process to restart
> 
> Hi,
> Running squid 3.2 snapshot starting up with -SYC  and seeing
> 
> 2012/01/12 16:06:30 kid8| Beginning Validation Procedure
> 2012/01/12 16:06:30 kid8| UFSSwapDir::doubleCheck: MISSING SWAP FILE
> 2012/01/12 16:06:30 kid8| UFSSwapDir::dumpEntry: FILENO 0053D933
> 2012/01/12 16:06:30 kid8| UFSSwapDir::dumpEntry: PATH /cache1/8/13/
> D9/0053D933
> 2012/01/12 16:06:30 kid8| StoreEntry->key:
> F6A9FB4E20007D04
> 2012/01/12 16:06:30 kid8| StoreEntry->next: 0
> 2012/01/12 16:06:30 kid8| StoreEntry->mem_obj: 0
> 2012/01/12 16:06:30 kid8| StoreEntry->timestamp: 4294967296
> 2012/01/12 16:06:30 kid8| StoreEntry->lastref: 16243941
> 2012/01/12 16:06:30 kid8| StoreEntry->expires: 2259152797697
> 2012/01/12 16:06:30 kid8| StoreEntry->lastmod: 1326384112
> 2012/01/12 16:06:30 kid8| StoreEntry->swap_file_sz: 1326384117
> 2012/01/12 16:06:30 kid8| StoreEntry->refcount: 1908
> 2012/01/12 16:06:30 kid8| StoreEntry->flags:
> SPECIAL
> ,REVALIDATE,DELAY_SENDING,CACHABLE,FWD_HDR_WAIT,NEGCACHED,BAD_LENGTH
> 2012/01/12 16:06:30 kid8| StoreEntry->swap_dirn: 0
> 2012/01/12 16:06:30 kid8| StoreEntry->swap_filen: 5495091
> 2012/01/12 16:06:30 kid8| StoreEntry->lock_count: 0
> 2012/01/12 16:06:30 kid8| StoreEntry->mem_status: 0
> 2012/01/12 16:06:30 kid8| StoreEntry->ping_status: 0
> 2012/01/12 16:06:30 kid8| StoreEntry->store_status: 0
> 2012/01/12 16:06:30 kid8| StoreEntry->swap_status: 2
> 2012/01/12 16:06:30 kid8|   Completed Validation Procedure
> 2012/01/12 16:06:30 kid8|   Validated 1 Entries
> 2012/01/12 16:06:30 kid8|   store_swap_size = 1295300.00 KB
> 2012/01/12 16:06:30 kid8| assertion failed: store_rebuild.cc:115:
> "store_errors == 0"
> nothing read from stdin
> nothing read from stdin
> 
> In cache.log
> Need a config file?
> 
> Rgds
> Alex
> 
> ==
> Time for another Macmillan Cancer Support event. This time its the 12
> day Escape to Africa challenge
> 
> View route at
> http://maps.google.co.uk/maps/ms?ie=UTF8&hl=en&msa=0&msid=203779866436035016780.00049e867720273b73c39&z=8
> 
> Please sponsor me at http://www.justgiving.com/Alex-Sharaz
> 


Yes I also saw this sometimes, I did not report because I'm waiting some news 
from others bugs before.

This crash is an unusual behaviour for you, or you have this messages everyday 
? 

Re: [squid-users] assertion failed: cbdata.cc:130: "cookie == ((long)this ^ Cookie)"

[John Hay]

Hi,

I have tried squid-3.2.0.17-20120611-r11586 and it still crash shortly
after starting.

So looking through the chnagelog for 3.2.0.17, the most likely culprit
seemed squid-3.2-11549.patch:

http://www.squid-cache.org/Versions/v3/3.2/changesets/squid-3.2-11549.patch

So I reversed that patch and now squid-3.2.0.17-20120611-r11586 has been
running stable for 5 hours.

John
-- 
John Hay -- j...@meraka.csir.co.za / j...@freebsd.org

On Wed, Jun 06, 2012 at 02:05:59PM +0200, John Hay wrote:
> Hi,
> 
> When upgrading from 3.2.0.16 to 3.2.0.17 I ran into this:
> 2012/06/06 12:19:56 kid1| assertion failed: cbdata.cc:130: "cookie == 
> ((long)this ^ Cookie)"
> 
> I have also tried squid-3.2.0.17-20120527-r11561, but see the same problem.
> I'll include my squid.conf, a piece of cache.log and the backtrace. This
> happen somewhere from a few seconds after starting squid to a few minutes
> later.
> 
> The machine is running FreeBSD 8.2-STABLE and up to now, I have not had
> such a problem with squid. I have been running the 3.2 branch for a while
> because I need the IPv6 -> IPv4 failover. The machine has 2 interfaces
> with one side having global IPv4 and IPv6 addresses and the other side
> have some private addresses. It also do transparent IPv4 proxying for
> those that did not configure a proxy.
> 
> Has anybody seen something like this? Can it be something in my config
> that is now catching up with me? I have not changed that in a while.
> 
> John
> -- 
> John Hay -- j...@meraka.csir.co.za / j...@freebsd.org

> acl local-servers dstdomain .csir.co.za
> acl local-servers dstdomain .fmfi.org.za
> acl to_ipv6 dst ipv6
> acl localnet src 10.0.0.0/8   # RFC1918 possible internal network
> acl localnet src 146.64.0.0/16
> acl localnet src 2001:4200:7000::/48
> acl localnet src fd9c:6829:597c::/48
> acl localdst dst 146.64.0.0/16
> acl localdst dst 10.0.0.0/8
> acl badsrc src 146.64.8.10
> acl SSL_ports port 443
> acl SSL_ports port 563
> acl SSL_ports port 7002   # 
> acl SSL_ports port 9001   # 
> acl Safe_ports port 80# http
> acl Safe_ports port 21# ftp
> acl Safe_ports port 443   # https
> acl Safe_ports port 70# gopher
> acl Safe_ports port 210   # wais
> acl Safe_ports port 1025-65535# unregistered ports
> acl Safe_ports port 280   # http-mgmt
> acl Safe_ports port 488   # gss-http
> acl Safe_ports port 591   # filemaker
> acl Safe_ports port 777   # multiling http
> acl Safe_ports port 800   # 
> acl CONNECT method CONNECT
> http_access allow manager localhost
> http_access deny manager
> http_access deny badsrc
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localnet
> http_access deny all
> icp_access allow localnet
> icp_access deny all
> htcp_access allow localnet
> htcp_access deny all
> http_port 146.64.8.8:3128
> http_port 127.0.0.1:3000 transparent
> http_port 3128
> icp_port 3130
> connect_timeout 5 seconds
> connect_retries 2
> hierarchy_stoplist cgi-bin ?
> cache_log /home/squid/logs/cache.log
> access_log /home/squid/logs/access.log squid
> refresh_pattern ^ftp: 144020% 10080
> refresh_pattern ^gopher:  14400%  1440
> refresh_pattern -i (/cgi-bin/|\?) 0   0%  0
> refresh_pattern . 0   20% 4320
> cache_mgr j...@meraka.org.za
> cache_effective_user squid
> cache_effective_group squid
> visible_hostname crypton.cids.org.za
> cache_mem 96 MB
> dns_defnames on
> coredump_dir /home/squid

> 2012/06/06 11:38:48 kid1| Starting Squid Cache version 
> 3.2.0.17-20120527-r11561 for amd64-portbld-freebsd8.2...
> 2012/06/06 11:38:48 kid1| Process ID 34071
> 2012/06/06 11:38:48 kid1| Process Roles: worker
> 2012/06/06 11:38:48 kid1| With 11095 file descriptors available
> 2012/06/06 11:38:48 kid1| Initializing IP Cache...
> 2012/06/06 11:38:48 kid1| DNS Socket created at [::], FD 7
> 2012/06/06 11:38:48 kid1| DNS Socket created at 0.0.0.0, FD 8
> 2012/06/06 11:38:48 kid1| Adding domain meraka.csir.co.za from 
> /etc/resolv.conf
> 2012/06/06 11:38:48 kid1| Adding domain cids.org.za from /etc/resolv.conf
> 2012/06/06 11:38:48 kid1| Adding nameserver 127.0.0.1 from /etc/resolv.conf
> 2012/06/06 11:38:48 kid1| Adding nameserver ::1 from /etc/resolv.conf
> 2012/06/06 11:38:48 kid1| Logfile: opening log /home/squid/logs/access.log
> 2012/06/06 11:38:48 kid1| WARNING: log parameters now start with a module 
> name. Use 'stdio:/home/squid/logs/access.log'
> 2012/06/06 11:38:48 kid1| Store logging disabled
> 2012/06/06 11:38:48 kid1| Swap maxSize 0 + 98304 KB, estimated 7561 objects
> 2012/06/06 11:38:48 kid1| Target number of buckets: 378
> 2012/06/06 11:38:48 kid1| Using 8192 Store buckets
> 2012/06/06 11:38:48 kid1| Max Mem  size: 98304 KB
> 2012/06/06 11:38:48 kid1| Max Swap size: 0 KB
> 2012/06/06 11:38:48 kid1| Using Least Load store dir selection
> 2012/06/0

Re: [squid-users] Assertion failed message then squid restart on 3.1.10 and 3.1.11

[Amos Jeffries]

On 11/02/11 01:57, Alex Sharaz wrote:

Hi,

Looking for hints as to how to resolve the above problem.

Occasionally I get

2011/02/10 09:25:42| assertion failed: htcp.cc:1350: "sz >= 0"
2011/02/10 09:25:52| Starting Squid Cache version 3.1.11 for
x86_64-unknown-linux-gnu...

Messages appearing in my cache.log.

The server in question is a test box that is linked into my production (
2.7.stable9) group of caches). I'd like to move to the 3.1 branch from
2.7 but am reluctant to do so while it occasionally breaks.

Any pointers as to how I might resolve the above?

I'm running squid on a 64 bit ubuntu (10.4) box with the following config

#!/bin/bash
ulimit -SHn 24576
./configure --enable-snmp --enable-basic-auth-helpers="PAM"
--enable-cachemgr-hostname=slb-realsrv1-east --enable-htcp
--enable-cache-digests --enable-async-io --prefix=/usr/local/squid
--with-pthreads --enable-removal-policies --enable-ssl
-with-openssl=/usr/local/ssl --enable-linux-netfilter -with-large-files
--with-maxfd=24576 --with-dl --enable-icmp --enable-poll
--disable-ident-lookups --enable-truncate --enable-delay-pools
--disable-ipv6 --disable-loadable-modules

Thanks
Alex



Ouch, quite nasty. I've applied patches to handle this to 3.HEAD. It 
should apply easily to earlier releases as well.


When the mirrors update it will be available at 
http://www.squid-cache.org/Versions/v3/3.HEAD/changesets/squid-3-11220.patch


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE9 or 3.1.11
  Beta testers wanted for 3.2.0.4

Re: [squid-users] assertion failed: comm.cc:1255: "isOpen(fd)" when shutting down squid 3.2 snapshot

[FredB]

Please open a bug report on Bugzilla

Note that Squid 3.2 is still unstable in production, however I think it's 
almost good now.

> 10:45:59 kid7 -> I'm using two workers - with diskd - maybe you should try 
> with less

- Mail original -
> De: "alex sharaz" 
> À: squid-users@squid-cache.org
> Envoyé: Jeudi 12 Janvier 2012 11:48:08
> Objet: [squid-users] assertion failed: comm.cc:1255: "isOpen(fd)" when 
> shutting down squid 3.2 snapshot
>
> Hi,
> excerpt from cache.log when running /usr/local/squid/sbin/squid -k
> shutdown
>
> 2012/01/12 10:45:59 kid7| Open FD READ/WRITE   82
> apps.facebook.com:443
> 2012/01/12 10:45:59 kid7| Open FD READ/WRITE   83
> apps.facebook.com:443
> 2012/01/12 10:45:59 kid7| Open FD READ/WRITE   84
> http://s0.2mdn.net/2986074/PID_1802528_160x600.swf
> 2012/01/12 10:45:59 kid7| Squid Cache (Version 3.2.0.14-20111228-
> r11479): Exiting normally.
> 2012/01/12 10:45:59 kid7| assertion failed: comm.cc:1255:
> "isOpen(fd)"
> FATAL: Received Segment Violation...dying.
> 2012/01/12 10:45:59 kid7| storeDirWriteCleanLogs: Starting...
> nothing read from stdin
> nothing read from stdin
> nothing read from stdin
> nothing read from stdin
> nothing read from stdin
>
> Rgds
> Alex
>
>

Re: [squid-users] assertion failed: errorpage.c:292: "mem->inmem_hi == 0" - squid exiting on signal 6

[Muthukumar]

> Squid 2.5STABLE5 on FreeBSD 4.6.2 (working on upgrading this)
>
>  From caceh.log:
> 2004/06/14 11:49:17| assertion failed: errorpage.c:292: "mem->inmem_hi
> == 0"
>
>  From messages:
> Jun 14 11:49:17 s067sqd01 /kernel: pid 31939 (squid), uid 65534: exited
> on signal 6
> Jun 14 11:49:17 s067sqd01 squid[22769]: Squid Parent: child process
> 31939 exited due to signal 6
>
> Squid is compiled with snmp.
>
> Any ideas on where to start?

There is bug and fix on this problem. Check here at
http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE5-post_assert

> I read something about incompatibilities with a Symantec virus
> scanner... we have the Squid box forwarding all requests to a Trend
> Micro AV proxy server.  Could this be causing the problem?
>

Make the changes of squid souce with that patch and recompile the squid. Check the 
squid now.

Regards,
Muthukumar.




---
===  It is a "Virus Free Mail" ===
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.705 / Virus Database: 461 - Release Date: 6/12/2004

Re: [squid-users] assertion failed: errorpage.c:292: "mem->inmem_hi == 0" - squid exiting on signal 6

[Gaylord Van Brocklin]

Perfect!
Patch implemented... seems to have cleared up the issue.
Thanks again.
-gvb
On Jun 14, 2004, at 9:07 PM, Muthukumar wrote:


Squid 2.5STABLE5 on FreeBSD 4.6.2 (working on upgrading this)
 From caceh.log:
2004/06/14 11:49:17| assertion failed: errorpage.c:292: "mem->inmem_hi
== 0"
 From messages:
Jun 14 11:49:17 s067sqd01 /kernel: pid 31939 (squid), uid 65534:  
exited
on signal 6
Jun 14 11:49:17 s067sqd01 squid[22769]: Squid Parent: child process
31939 exited due to signal 6

Squid is compiled with snmp.
Any ideas on where to start?
There is bug and fix on this problem. Check here at
http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE5- 
post_assert

I read something about incompatibilities with a Symantec virus
scanner... we have the Squid box forwarding all requests to a Trend
Micro AV proxy server.  Could this be causing the problem?
Make the changes of squid souce with that patch and recompile the  
squid. Check the squid now.

Regards,
Muthukumar.

---
===  It is a "Virus Free Mail" ===
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.705 / Virus Database: 461 - Release Date: 6/12/2004

Re: [squid-users] assertion failed: errorpage.c:292: "mem->inmem_hi == 0" - squid exiting on signal 6

[Gaylord Van Brocklin]

I spoke to soon... we have a new issue.  This just happened after  
running fine for a few hours:

From cache.log:
FATAL: Received Segment Violation...dying.
2004/06/15 12:40:30| storeDirWriteCleanLogs: Starting...
2004/06/15 12:40:30| WARNING: Closing open FD7
2004/06/15 12:40:30| 65536 entries written so far.
2004/06/15 12:40:30|131072 entries written so far.
2004/06/15 12:40:30|196608 entries written so far.
2004/06/15 12:40:30|262144 entries written so far.
2004/06/15 12:40:30|327680 entries written so far.
2004/06/15 12:40:30|393216 entries written so far.
2004/06/15 12:40:31|458752 entries written so far.
2004/06/15 12:40:31|524288 entries written so far.
2004/06/15 12:40:30|327680 entries written so far.
2004/06/15 12:40:30|393216 entries written so far.
2004/06/15 12:40:31|458752 entries written so far.
2004/06/15 12:40:31|524288 entries written so far.
2004/06/15 12:40:31|589824 entries written so far.
2004/06/15 12:40:31|655360 entries written so far.
2004/06/15 12:40:31|720896 entries written so far.
2004/06/15 12:40:31|786432 entries written so far.
2004/06/15 12:40:31|851968 entries written so far.
2004/06/15 12:40:32|917504 entries written so far.
2004/06/15 12:40:32|   Finished.  Wrote 969981 entries.
2004/06/15 12:40:32|   Took 2.1 seconds (452637.6 entries/sec).
CPU Usage: 6401.555 seconds = 3387.023 user + 3014.532 sys
Maximum Resident Size: 1015920 KB
Page faults with physical i/o: 0
From messages:
Jun 15 12:40:33 squid01 /kernel: pid 44914 (squid), uid 65534: exited  
on signal 6
Jun 15 12:40:33 squid01 squid[44911]: Squid Parent: child process 44914  
exited due to signal 6

I just reconfigured squid to dump core, so if this happens again we can  
trace the issue. but, any ideas?

-gvb
On Jun 14, 2004, at 9:07 PM, Muthukumar wrote:


Squid 2.5STABLE5 on FreeBSD 4.6.2 (working on upgrading this)
 From caceh.log:
2004/06/14 11:49:17| assertion failed: errorpage.c:292: "mem->inmem_hi
== 0"
 From messages:
Jun 14 11:49:17 s067sqd01 /kernel: pid 31939 (squid), uid 65534:  
exited
on signal 6
Jun 14 11:49:17 s067sqd01 squid[22769]: Squid Parent: child process
31939 exited due to signal 6

Squid is compiled with snmp.
Any ideas on where to start?
There is bug and fix on this problem. Check here at
http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE5- 
post_assert

I read something about incompatibilities with a Symantec virus
scanner... we have the Squid box forwarding all requests to a Trend
Micro AV proxy server.  Could this be causing the problem?
Make the changes of squid souce with that patch and recompile the  
squid. Check the squid now.

Regards,
Muthukumar.

---
===  It is a "Virus Free Mail" ===
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.705 / Virus Database: 461 - Release Date: 6/12/2004

Re: [squid-users] assertion failed: errorpage.c:292: "mem->inmem_hi == 0" - squid exiting on signal 6

[Henrik Nordstrom]

On Tue, 15 Jun 2004, Gaylord Van Brocklin wrote:

> I spoke to soon... we have a new issue.  This just happened after  
> running fine for a few hours:
> 
>  From cache.log:
> FATAL: Received Segment Violation...dying.

On all Segmentation Violation errors please see the Squid FAQ on how to 
report bugs. Back trace or reliable test case reproducing the problem is 
required to be able to process the bug report.

Regards
Henrik

Re: [squid-users] assertion failed: errorpage.c:292: "mem->inmem_hi == 0" - squid exiting on signal 6

[Gaylord Van Brocklin]

Ok.. it just crashed again after about 2 hours, around the same memory 
usage size:

core trace:
squid01# gdb squid squid.core
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and 
you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "i386-unknown-freebsd"...
Core was generated by `squid'.
Program terminated with signal 6, Abort trap.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x68178b0c in kill () from /usr/lib/libc.so.4
(gdb) where
#0  0x68178b0c in kill () from /usr/lib/libc.so.4
#1  0x681b8ef6 in abort () from /usr/lib/libc.so.4
#2  0x80b5328 in death (sig=11) at tools.c:303
#3  0xbfbfffac in ?? ()
#4  0x80842e0 in httpStateFree (fd=457, data=0x9c2d710) at http.c:68
#5  0x806ad0f in commCallCloseHandlers (fd=457) at comm.c:574
#6  0x806af1e in comm_close (fd=457) at comm.c:656
#7  0x80855b4 in httpReadReply (fd=457, data=0x9c2d710) at http.c:617
#8  0x806cb1f in comm_poll (msec=8) at comm_select.c:445
#9  0x8094d9e in main (argc=1, argv=0xbfbffdc4) at main.c:743
#10 0x804a3e9 in _start ()

From logs:
FATAL: Received Segment Violation...dying.
2004/06/15 15:10:21| storeDirWriteCleanLogs: Starting...
2004/06/15 15:10:21| WARNING: Closing open FD   10
2004/06/15 15:10:21| 65536 entries written so far.
2004/06/15 15:10:21|131072 entries written so far.
2004/06/15 15:10:22|196608 entries written so far.
2004/06/15 15:10:22|262144 entries written so far.
2004/06/15 15:10:22|327680 entries written so far.
2004/06/15 15:10:22|393216 entries written so far.
2004/06/15 15:10:22|458752 entries written so far.
2004/06/15 15:10:22|524288 entries written so far.
2004/06/15 15:10:22|589824 entries written so far.
2004/06/15 15:10:22|655360 entries written so far.
2004/06/15 15:10:23|720896 entries written so far.
2004/06/15 15:10:23|786432 entries written so far.
2004/06/15 15:10:23|851968 entries written so far.
2004/06/15 15:10:23|917504 entries written so far.
2004/06/15 15:10:23|   Finished.  Wrote 945384 entries.
2004/06/15 15:10:23|   Took 2.1 seconds (453745.4 entries/sec).
CPU Usage: 7377.764 seconds = 3850.927 user + 3526.837 sys
Maximum Resident Size: 1015968 KB
Page faults with physical i/o: 0
Jun 15 15:11:18 s067sqd01 /kernel: pid 86715 (squid), uid 65534: exited 
on signal 6 (core dumped)
Jun 15 15:11:18 s067sqd01 squid[76758]: Squid Parent: child process 
86715 exited due to signal 6

-gvb
On Jun 15, 2004, at 2:10 PM, Henrik Nordstrom wrote:
On Tue, 15 Jun 2004, Gaylord Van Brocklin wrote:
I spoke to soon... we have a new issue.  This just happened after
running fine for a few hours:
 From cache.log:
FATAL: Received Segment Violation...dying.
On all Segmentation Violation errors please see the Squid FAQ on how to
report bugs. Back trace or reliable test case reproducing the problem 
is
required to be able to process the bug report.

Regards
Henrik

Re: [squid-users] assertion failed: errorpage.c:292: "mem->inmem_hi == 0" - squid exiting on signal 6

[Henrik Nordstrom]

Please file a bug report per the instructions in the Squid FAQ.

Also include the exact Squid version you are using, including which 
patches (if any) you have applied.

Regards
Henrik

On Tue, 15 Jun 2004, Gaylord Van Brocklin wrote:

> Ok.. it just crashed again after about 2 hours, around the same memory 
> usage size:
> 
> core trace:
> 
> squid01# gdb squid squid.core
> GNU gdb 4.18 (FreeBSD)
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and 
> you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for 
> details.
> This GDB was configured as "i386-unknown-freebsd"...
> Core was generated by `squid'.
> Program terminated with signal 6, Abort trap.
> Reading symbols from /usr/lib/libcrypt.so.2...done.
> Reading symbols from /usr/lib/libm.so.2...done.
> Reading symbols from /usr/lib/libc.so.4...done.
> Reading symbols from /usr/libexec/ld-elf.so.1...done.
> #0  0x68178b0c in kill () from /usr/lib/libc.so.4
> (gdb) where
> #0  0x68178b0c in kill () from /usr/lib/libc.so.4
> #1  0x681b8ef6 in abort () from /usr/lib/libc.so.4
> #2  0x80b5328 in death (sig=11) at tools.c:303
> #3  0xbfbfffac in ?? ()
> #4  0x80842e0 in httpStateFree (fd=457, data=0x9c2d710) at http.c:68
> #5  0x806ad0f in commCallCloseHandlers (fd=457) at comm.c:574
> #6  0x806af1e in comm_close (fd=457) at comm.c:656
> #7  0x80855b4 in httpReadReply (fd=457, data=0x9c2d710) at http.c:617
> #8  0x806cb1f in comm_poll (msec=8) at comm_select.c:445
> #9  0x8094d9e in main (argc=1, argv=0xbfbffdc4) at main.c:743
> #10 0x804a3e9 in _start ()
> 
>  From logs:
> FATAL: Received Segment Violation...dying.
> 2004/06/15 15:10:21| storeDirWriteCleanLogs: Starting...
> 2004/06/15 15:10:21| WARNING: Closing open FD   10
> 2004/06/15 15:10:21| 65536 entries written so far.
> 2004/06/15 15:10:21|131072 entries written so far.
> 2004/06/15 15:10:22|196608 entries written so far.
> 2004/06/15 15:10:22|262144 entries written so far.
> 2004/06/15 15:10:22|327680 entries written so far.
> 2004/06/15 15:10:22|393216 entries written so far.
> 2004/06/15 15:10:22|458752 entries written so far.
> 2004/06/15 15:10:22|524288 entries written so far.
> 2004/06/15 15:10:22|589824 entries written so far.
> 2004/06/15 15:10:22|655360 entries written so far.
> 2004/06/15 15:10:23|720896 entries written so far.
> 2004/06/15 15:10:23|786432 entries written so far.
> 2004/06/15 15:10:23|851968 entries written so far.
> 2004/06/15 15:10:23|917504 entries written so far.
> 2004/06/15 15:10:23|   Finished.  Wrote 945384 entries.
> 2004/06/15 15:10:23|   Took 2.1 seconds (453745.4 entries/sec).
> CPU Usage: 7377.764 seconds = 3850.927 user + 3526.837 sys
> Maximum Resident Size: 1015968 KB
> Page faults with physical i/o: 0
> 
> Jun 15 15:11:18 s067sqd01 /kernel: pid 86715 (squid), uid 65534: exited 
> on signal 6 (core dumped)
> Jun 15 15:11:18 s067sqd01 squid[76758]: Squid Parent: child process 
> 86715 exited due to signal 6
> 
> -gvb
> 
> On Jun 15, 2004, at 2:10 PM, Henrik Nordstrom wrote:
> 
> > On Tue, 15 Jun 2004, Gaylord Van Brocklin wrote:
> >
> >> I spoke to soon... we have a new issue.  This just happened after
> >> running fine for a few hours:
> >>
> >>  From cache.log:
> >> FATAL: Received Segment Violation...dying.
> >
> > On all Segmentation Violation errors please see the Squid FAQ on how to
> > report bugs. Back trace or reliable test case reproducing the problem 
> > is
> > required to be able to process the bug report.
> >
> > Regards
> > Henrik
> >
> 

Re: [squid-users] assertion failed: errorpage.c:292: "mem->inmem_hi == 0" - squid exiting on signal 6

[Henrik Nordstrom]

On Mon, 14 Jun 2004, Gaylord Van Brocklin wrote:

> I read something about incompatibilities with a Symantec virus 
> scanner... we have the Squid box forwarding all requests to a Trend 
> Micro AV proxy server.  Could this be causing the problem?

For Trend Micro AV proxy server you need "server_persistent_connections 
off" in squid.conf to work around bugs in the Trend proxy. This is also 
true for many other such "simple" proxy servers designed with other 
functions than proxying as their primary goal..

Regards
Henrik

Re: [squid-users] assertion failed: errorpage.c:292: "mem->inmem_hi == 0" - squid exiting on signal 6

[Gaylord Van Brocklin]

Henrik,
What kind of impact would I see with the default setting?  Would 
changing it to off increase performance?

-gvb
On Jul 25, 2004, at 10:01 AM, Henrik Nordstrom wrote:
On Mon, 14 Jun 2004, Gaylord Van Brocklin wrote:
I read something about incompatibilities with a Symantec virus
scanner... we have the Squid box forwarding all requests to a Trend
Micro AV proxy server.  Could this be causing the problem?
For Trend Micro AV proxy server you need "server_persistent_connections
off" in squid.conf to work around bugs in the Trend proxy. This is also
true for many other such "simple" proxy servers designed with other
functions than proxying as their primary goal..
Regards
Henrik

Re: [squid-users] assertion failed: errorpage.c:292: "mem->inmem_hi == 0" - squid exiting on signal 6

[Henrik Nordstrom]

On Fri, 30 Jul 2004, Gaylord Van Brocklin wrote:

> What kind of impact would I see with the default setting?  Would 
> changing it to off increase performance?

Setting it to "Off" will decrease performance somewhat, but given the 
quite server impact of the bug in your upstream virusscanning proxy the 
tradeoff is minimal.

Regards
Henrik

Re: [squid-users] assertion failed: Checklist.cc:287: "!needsAsync && !matchFinished" after upgrade from squid 3.2.7 to 3.3.3

[Amm]

- Original Message -
> From: Dieter Bloms 
> To: squid-users@squid-cache.org
> Cc: 
> Sent: Wednesday, 10 April 2013 3:03 PM
> Subject: [squid-users] assertion failed: Checklist.cc:287: "!needsAsync && 
> !matchFinished" after upgrade from squid 3.2.7 to 3.3.3
> 
> Hi,
> 
> I run 3.2.7 squid successfully for some weeks now.
> Yesterday I tried to upgrade to squid 3.3.3 and after a few minutes
> squid exits and I get the following messages in my cache.log:
> 
> --snip--
> 2013/04/09 08:46:50| assertion failed: Checklist.cc:287: "!needsAsync 
> && !matchFinished"
> 2013/04/09 08:46:52| Starting Squid Cache version 3.3.3 for 
> x86_64-suse-linux-gnu...
> --snip--


This is known bug in 3.3 series. Even I faced it.

You can use the backported patch I have added at:

http://bugs.squid-cache.org/show_bug.cgi?id=3717


Note that patch does not solve the actual bug. Patch just adds -n acl
option with which you can disable DNS checks (which cause
the crash)


Amm.

Re: [squid-users] assertion failed: Checklist.cc:287: "!needsAsync && !matchFinished" after upgrade from squid 3.2.7 to 3.3.3

[Dieter Bloms]

Hello Amm,

On Wed, Apr 10, Amm wrote:

> - Original Message -
> > From: Dieter Bloms 
> > To: squid-users@squid-cache.org
> > Cc: 
> > Sent: Wednesday, 10 April 2013 3:03 PM
> > Subject: [squid-users] assertion failed: Checklist.cc:287: "!needsAsync && 
> > !matchFinished" after upgrade from squid 3.2.7 to 3.3.3
> > 
> > Hi,
> > 
> > I run 3.2.7 squid successfully for some weeks now.
> > Yesterday I tried to upgrade to squid 3.3.3 and after a few minutes
> > squid exits and I get the following messages in my cache.log:
> > 
> > --snip--
> > 2013/04/09 08:46:50| assertion failed: Checklist.cc:287: "!needsAsync 
> > && !matchFinished"
> > 2013/04/09 08:46:52| Starting Squid Cache version 3.3.3 for 
> > x86_64-suse-linux-gnu...
> > --snip--
> 
> 
> This is known bug in 3.3 series. Even I faced it.
> 
> You can use the backported patch I have added at:
> 
> http://bugs.squid-cache.org/show_bug.cgi?id=3717
> 
> 
> Note that patch does not solve the actual bug. Patch just adds -n acl
> option with which you can disable DNS checks (which cause
> the crash)

we use blacklist based on ips and domains, so I have to use PTR lookups.
But thank you for the note to the bugreport.  I will follow it.


-- 
Best regards

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.