[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    Re: [squid-dev] Regression introduced in r14268
From:       Alex Rousskov <rousskov () measurement-factory ! com>
Date:       2015-08-31 4:21:13
Message-ID: 55E3D639.90600 () measurement-factory ! com
[Download RAW message or body]

On 08/30/2015 01:50 PM, Amos Jeffries wrote:

> After fixing that I am now getting:
> 
> #3  0x083316dd in xassert (msg=0x8703069 "c->locks > 0", file=0x8702ed3
> "../../src/cbdata.cc", line=425) at ../../src/debug.cc:556
> 
> Hey reproducible case for *that* long annoying bug !!
> 
> #4  0x082d7feb in cbdataReferenceValid (p=0x8c92e48) at
> ../../src/cbdata.cc:425
> #5  0x082fe3f0 in ACLChecklist::changeAcl (this=0xbffff110, t=0x0) at
> ../../src/acl/Checklist.h:175
> #6  0x084d972b in ACLChecklist::fastCheck (this=0xbffff110,
> list=0x8c92e48) at ../../../src/acl/Checklist.cc:326
> #7  0x0863b5a6 in accessLogLogTo (log=0x8a7c780, al=...,
> checklist=0xbffff110) at ../../../src/log/access_log.cc:96


I do not think the new changeAcl() method should be used in fastCheck().
The handling of the original ACL list there is different from [even
though the code looks similar to] what changeAcl() now does. When we
discussed adding that new method, I did not realize you would use it in
fastCheck() as well.

The fact that fastCheck(void), fastCheck(acl), and nonBlockingCheck()
are slightly and confusingly different when it comes to access list
management is essentially an [API] bug, but it is not a bug we can or
should solve with the new changeAcl() method.


HTH,

Alex.

_______________________________________________
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

[prev in list] [next in list] [prev in thread] [next in thread]