Buffer leak (Re: FD leak, except, not really)

From: Stephen R. van den Berg <srb@dont-contact.us>
Date: Wed, 8 Jul 1998 09:30:02 +0200

>Eric Stern wrote:
>> It seems to be related to async-io. (ie if you aren't using async-io, you
>> don't get this problem). I'm still playing with it, but on one of my test
>> boxes I seemed to have fixed it by commenting out the async sections of
>> file_open in disk.c. This is not a fix, just a workaround, since that

Henrik Nordstrom wrote:
>I have a preleminary patch that I hope fixes the problem. It is
>available from http://hem.passagen.se/hno/squid/ as usual.

Ok, this fixes the FD leak (definitely). However, related to the
FD leak, there still is a 4K_BUFFER leak. I.e. statistics seem
to confirm that for every FD that was lost, there is a corresponding
4K_BUFFER which gets lost in the woods as well.

With the patch applied, the result is that the FD leak has been stopped,
but the 4K_BUFFERS are still getting lost at approximately the same
rate as before.

Also, there seem to be a growing number of "NOT VALID 1 locks" cbdata entries.
The number is not quite so large as the total number of lost 4K_BUFFERS,
but seems to be offset from it with a certain constant.
I.e. currently I have 473 allocated 4K_BUFFERS (of which approximately 400
have been lost), 394 cbdata entries (of which 164 are marked as
"NOT VALID 1 locks"; the rest are "VALID 0 locks").

Sincerely,                                                          srb@cuci.nl
           Stephen R. van den Berg (AKA BuGless).
"Always look on the bright side of life!"
Received on Wed Jul 08 1998 - 00:31:08 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:41:04 MST