From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 16 Oct 2014 18:39:55 +0000 (-0700)
Subject: CBDATA: log memory leak situations when --enable-debug-cbdata
X-Git-Tag: SQUID_3_4_9~10
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=d2f1b9d2918fbc360cb337e171cd520e068806a6;p=thirdparty%2Fsquid.git

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.
---

diff --git a/src/cbdata.cc b/src/cbdata.cc
index 7c656c7ee0..156ce3690b 100644
--- a/src/cbdata.cc
+++ b/src/cbdata.cc
@@ -465,9 +465,16 @@ cbdataInternalUnlock(const void *p)
 
     -- c->locks;
 
-    if (c->valid || c->locks)
+    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;
 
     debugs(45, 9, "cbdataUnlock: Freeing " << p);