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

>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!"