weird storeentry leak in 2-head

From: Adrian Chadd <>
Date: Thu, 25 Jan 2007 21:07:16 +0800

I'm running a simple datacomm-1 workload against squid-2-head and I'm finding
the thing is leaking storeentry's all over the place. The symptom is that
the MEM_MEM_NODE pool grows forever. I looked into it and found most of the
store entries were marked "release request" with one lock and nothing to
tidy it up. The only store entries which were being considered for reaping
by the memory replacement policy were those who weren't jammed in this state.
The ones who are jammed in this state were somehow removed from the policy
but didn't have their memory cleaned so all the 'fine' objects were being
quickly discarded.

Here's an example:

KEY 9228D59CF2585E28AB922554BEB4D152
        LV:1169728835 LU:1169728833 LM:-1 EX:1169728835
        1 locks, 0 clients, 1 refs
        Swap Dir -1, File 0XFFFFFFFF
        inmem_lo: 24576
        inmem_hi: 26087
        swapout: 0 bytes queued

The locking primitives are:

2007/01/25 20:40:33| storeLockObject: (store_client.c:122): key '9228D59CF2585E28AB922554BEB4D152' count=2
2007/01/25 20:40:33| storeLockObject: (forward.c:877): key '9228D59CF2585E28AB922554BEB4D152' count=3
2007/01/25 20:40:33| storeLockObject: (peer_select.c:155): key '9228D59CF2585E28AB922554BEB4D152' count=4
2007/01/25 20:40:33| storeLockObject: (http.c:1423): key '9228D59CF2585E28AB922554BEB4D152' count=5
2007/01/25 20:40:33| storeUnlockObject: (peer_select.c:109): key '9228D59CF2585E28AB922554BEB4D152' count=4
2007/01/25 20:40:36| storeUnlockObject: (http.c:75): key '9228D59CF2585E28AB922554BEB4D152' count=3
2007/01/25 20:40:36| storeUnlockObject: (store_client.c:540): key '9228D59CF2585E28AB922554BEB4D152' count=2
2007/01/25 20:40:36| storeUnlockObject: (client_side.c:1332): key '9228D59CF2585E28AB922554BEB4D152' count=1

Hm, there's no call there to storeUnlockObject at all because of fwdStateFree?
That might be the missing unlock. But where'd it go?

Received on Thu Jan 25 2007 - 06:02:00 MST

This archive was generated by hypermail pre-2.1.9 : Thu Feb 01 2007 - 12:00:02 MST