ons 2009-02-11 klockan 19:06 -0700 skrev Alex Rousskov:
Is it possible that indirectly lost is not really lost?
Yes, as this is a trace at shutdown, and our module shutdown methods is
not very great.
Also not sure if this Squid was built with valgrind support or not. If
not then valgrind leak
Alex Rousskov wrote:
On 02/11/2009 07:56 PM, Amos Jeffries wrote:
On 02/11/2009 06:08 PM, Amos Jeffries wrote:
Is there any definitely lost record?
nly minor stuff which isn't memPool'd
s it possible that indirectly lost is not really lost?
No. From the valgrind manual on
Hi Amos,
Is there any definitely lost record?
Amos Jeffries wrote:
We seem to have tracked the major leak ( ~1MB per request) down to these:
mem_obj-delayRead(DeferredRead(DeferReader, this, CommRead(fd, buf,
len, callback)));
Which generate:
==21688== 1,251,224 bytes in 12,031
Hi Amos,
Is there any definitely lost record?
Only minor stuff which isn't memPool'd
Amos Jeffries wrote:
We seem to have tracked the major leak ( ~1MB per request) down to
these:
mem_obj-delayRead(DeferredRead(DeferReader, this, CommRead(fd, buf,
len, callback)));
Which
On 02/11/2009 06:08 PM, Amos Jeffries wrote:
Is there any definitely lost record?
Only minor stuff which isn't memPool'd
Is it possible that indirectly lost is not really lost?
Thank you,
Alex.
Amos Jeffries wrote:
We seem to have tracked the major leak ( ~1MB per
On 02/11/2009 06:08 PM, Amos Jeffries wrote:
Is there any definitely lost record?
Only minor stuff which isn't memPool'd
Is it possible that indirectly lost is not really lost?
No. From the valgrind manual on direct vs indirect leaks:
The distinction is that a direct leak is a block
We seem to have tracked the major leak ( ~1MB per request) down to these:
mem_obj-delayRead(DeferredRead(DeferReader, this, CommRead(fd, buf,
len, callback)));
Which generate:
==21688== 1,251,224 bytes in 12,031 blocks are indirectly lost in loss
record 26 of 30
==21688==at
