On 25/02/2016 11:44 a.m., Dan Charlesworth wrote:
> I’m just catching up with this one, but we’ve observed some memory leaks on a
> small percentage of our boxes, which we migrated to Peek & Splice late last
> year.
>
> We’re on 3.5.13, about to move to 3.5.15.
>
> What’s the least disruptive
I’m just catching up with this one, but we’ve observed some memory leaks on a
small percentage of our boxes, which we migrated to Peek & Splice late last
year.
We’re on 3.5.13, about to move to 3.5.15.
What’s the least disruptive way to keep this under control, if there is one?
Is there anyth
On 24/02/2016 11:17 p.m., Steve Hill wrote:
> On 23/02/16 21:28, Amos Jeffries wrote:
>
>> Ah, you said "a small number" of wiki cert strings with those details. I
>> took that as meaning a small number of definitely squid generated ones
>> amidst the 130K indeterminate ones leaking.
>
> Ah, a mi
On 23/02/16 21:28, Amos Jeffries wrote:
Ah, you said "a small number" of wiki cert strings with those details. I
took that as meaning a small number of definitely squid generated ones
amidst the 130K indeterminate ones leaking.
Ah, a misunderstanding on my part - sorry. Yes, there were 302 st
On 24/02/2016 10:08 a.m., Steve Hill wrote:
> On 23/02/16 17:30, Amos Jeffries wrote:
>
>> And a leak (real or pseudo) means they are still hanging around in
>> memory for some reason other than cert-cache references (being in the
>> cache by definition is not-leaking). For example as part of acti
On 23/02/16 17:30, Amos Jeffries wrote:
> And a leak (real or pseudo) means they are still hanging around in
> memory for some reason other than cert-cache references (being in the
> cache by definition is not-leaking). For example as part of active TLS
> sessions when the core was produced.
Seem
On 24/02/2016 4:31 a.m., Steve Hill wrote:
>
> There are also a very small number of lines that look something like:
> /C=US/ST=California/L=San Francisco/O=Wikimedia Foundation,
> Inc./CN=*.wikipedia.org+Sign=signTrusted+SignHash=SHA256
> I think the "+Sign=signTrusted+SignHash=SHA256" part w
I'm looking into (what appears to be) a memory leak in the Squid 3.5
series. I'm testing this in 3.5.13, but this problem has been observed
in earlier releases too. Unfortunately I haven't been able to reproduce
the problem in a test environment yet, so my debugging has been limited
to what
