Re: [PATCH] Improve Configuration Checking and Parsing

On 7/01/2013 10:42 p.m., Kinkie wrote: IMO, Squid should abort when it cannot be sure its interpretation of a configured value is correct. I agree that, in some cases, the caller is more knowledgeable about parsing context and may decide to proceed anyway or generate a better error message.

Re: [PATCH] Improve Configuration Checking and Parsing

On 6/01/2013 1:12 p.m., Tianyin Xu wrote: Hi, Amos, I addressed your audit results one by one (see my reply below each audit entry). The updated patches is attached. Two things I want to mention in the very beginning: 1. I checked the version according to your information, and made sure it's

Re: [PATCH] address.GetPort() != 0 assertion for helpers on FreeBSD

On 9/01/2013 6:13 p.m., Alex Rousskov wrote: Hello, Some v3.3 and trunk helpers are broken on FreeBSD and possibly some other non-Linux OSes. Squid using ssl_crtd, URL rewriter, and possibly other helpers asserts on startup: assertion failed: comm.cc:800: address.GetPort() != 0 Our

Re: CentOS-6 node added to build farm

On 1/7/2013 11:30 AM, Kinkie wrote: Hi all, I've added a CentOS 6.3 node to the build farm, and set it up to build trunk (not yet added to the main automated build run). It shows brokenness in OpenSSL; may it be due to the API version fudge by RedHat? Does anyone have any idea on how to fix

Re: CentOS-6 node added to build farm

On 10/01/2013 10:13 p.m., Eliezer Croitoru wrote: On 1/7/2013 11:30 AM, Kinkie wrote: Hi all, I've added a CentOS 6.3 node to the build farm, and set it up to build trunk (not yet added to the main automated build run). It shows brokenness in OpenSSL; may it be due to the API version fudge

Re: CentOS-6 node added to build farm

On 1/10/2013 11:28 AM, Amos Jeffries wrote: On 10/01/2013 10:13 p.m., Eliezer Croitoru wrote: On 1/7/2013 11:30 AM, Kinkie wrote: Hi all, I've added a CentOS 6.3 node to the build farm, and set it up to build trunk (not yet added to the main automated build run). It shows brokenness in

Re: [PATCH] address.GetPort() != 0 assertion for helpers on FreeBSD

Hi, I second Amos' suggestion, +1 from me as well if it's followed. On Thu, Jan 10, 2013 at 10:07 AM, Amos Jeffries squ...@treenet.co.nz wrote: On 9/01/2013 6:13 p.m., Alex Rousskov wrote: Hello, Some v3.3 and trunk helpers are broken on FreeBSD and possibly some other non-Linux

Build bug in test-suite

Hi all, there's a bug in the testsuite: if the configure options don't include the LRU removal policy, then testUFS will fail building due to missing createRemovalPolicy_lru. The behavior seems pretty hard-coded in the unit test, I couldn't immediately find a way to work around the issue. I'll

Build failed in Jenkins: 3.2-matrix » obsd-49-x86 #289

See http://build.squid-cache.org/job/3.2-matrix/./label=obsd-49-x86/289/changes Changes: [Amos Jeffries] 3.2.6 [Amos Jeffries] Bug 3731: TOS setsockopt() requires int value FreeBSD is confirmed errors on 8-bit variable size. Other BSD are documented in a way that implies they do as well,

Build failed in Jenkins: 3.3-matrix » obsd-49-x86 #21

See http://build.squid-cache.org/job/3.3-matrix/./label=obsd-49-x86/21/ -- Started by upstream project 3.3-matrix build number 21 originally caused by: Started by an SCM change Building remotely on obsd-49-x86 in workspace

Build failed in Jenkins: 3.1-matrix » obsd-49-x86 #157

See http://build.squid-cache.org/job/3.1-matrix/./label=obsd-49-x86/157/ -- Started by upstream project 3.1-matrix build number 157 originally caused by: Started by an SCM change Building remotely on obsd-49-x86 in workspace

Jenkins build is back to normal : 3.HEAD-amd64-FreeBSD-9.0-clang #116

See http://build.squid-cache.org/job/3.HEAD-amd64-FreeBSD-9.0-clang/116/changes

RE: ConnOpener leaks in 3.2.5

I'm able to replicate a leak at will. When the client makes a request to a non-responsive server, the ConnOperner object leaks with a non-zero lock count. I've traced the problem to the use of 'new Pointer(this)' in ConnOpener::connect(). When the connection is in progress, the SetSelect() call

Re: ConnOpener leaks in 3.2.5

On 01/10/2013 02:30 PM, Mike Mitchell wrote: I'm able to replicate a leak at will. When the client makes a request to a non-responsive server, the ConnOperner object leaks with a non-zero lock count. I've traced the problem to the use of 'new Pointer(this)' in ConnOpener::connect(). When

Build failed in Jenkins: 3.2-matrix » obsd-49-x86 #290

See http://build.squid-cache.org/job/3.2-matrix/./label=obsd-49-x86/290/ -- Started by upstream project 3.2-matrix build number 290 originally caused by: Started by an SCM change Building remotely on obsd-49-x86 in workspace

Re: [PATCH] StoreID latest implementation in sync with rev 12552. stage 2-3 from 3.

On 4/01/2013 7:10 a.m., Eliezer Croitoru wrote: Thanks Alex, On 1/3/2013 6:23 PM, Alex Rousskov wrote: One of the reasons is that sooner or later the current or updated code will crash while accessing the request in these situations. Just because you have carefully identified when the request

[RFC] remove negative_ttl directive ?

The negative_ttl directive is continuously causing problems. What it does is DoS all clients of a proxy when one of them has a URL problem. In modern websites which can present per-client error responses targeted at an individual client this can be a major problem. I propose dropping the

Re: [RFC] remove negative_ttl directive ?

Hi all, since we have it already what about taking a softer stance? For instance, subject it to an hard-coded maximum limit of a few seconds/minutes, or display a strong warning to cache.log when a value above a certain time limit is found during parsing.. On Fri, Jan 11, 2013 at 6:53 AM, Amos