------------------------------------------------------------
revno: 13177
revision-id: squid3@treenet.co.nz-20141016183955-9ev7jgxu5jqu00vr
parent: squid3@treenet.co.nz-20141009115328-975fts0dt6hamnid
committer: Amos Jeffries <squid3@treenet.co.nz>
branch nick: 3.4
timestamp: Thu 2014-10-16 11:39:55 -0700
message:
  CBDATA: log memory leak situations when --enable-debug-cbdata
  
  CBDATA objects are supposed to be explicitly locked and unlocked by all
  users. The nominal 'owner' of the data is also supposed to mark it as
  invalid when unlocking its reference.
  
  If a CBDATA object reaches 0 locks and is still valid, it therefore
  follows that either the locking or invalidate has not been properly
  implemented.
  
  Now that we are migrating to CbcPointer usage instead of explicit
  lock/unlock macro calls we have started encountering these situations.
  Any object reporting a 'leak' must be investigated;
   a) perhapse RefCount is better?
   b) using CbcPointer consistently and invalidating correctly.
------------------------------------------------------------
# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: squid3@treenet.co.nz-20141016183955-9ev7jgxu5jqu00vr
# target_branch: http://bzr.squid-cache.org/bzr/squid3/3.4
# testament_sha1: d2e02c0f965f90cb906a916d94b90960a3767f8b
# timestamp: 2014-10-16 18:50:43 +0000
# source_branch: http://bzr.squid-cache.org/bzr/squid3/3.4
# base_revision_id: squid3@treenet.co.nz-20141009115328-\
#   975fts0dt6hamnid
# 
# Begin patch
=== modified file 'src/cbdata.cc'
--- src/cbdata.cc	2012-09-01 14:38:36 +0000
+++ src/cbdata.cc	2014-10-16 18:39:55 +0000
@@ -465,8 +465,15 @@
 
     -- c->locks;
 
-    if (c->valid || c->locks)
-        return;
+    if (c->locks)
+        return;
+
+    if (c->valid) {
+#if USE_CBDATA_DEBUG
+        debugs(45, DBG_IMPORTANT, "CBDATA memory leak. cbdata=" << p << " " << file << ":" << line);
+#endif
+        return;
+    }
 
     --cbdataCount;