From: Eduard Bagdasaryan <eduard.bagdasaryan@measurement-factory.com>
Date: Mon, 25 Dec 2023 02:20:19 +0000 (+0000)
Subject: Bug 5329: cbdata.cc:276 "c->locks > 0" assertion on reconfigure (#1625)
X-Git-Tag: SQUID_7_0_1~247
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4657405;p=thirdparty%2Fsquid.git

Bug 5329: cbdata.cc:276 "c->locks > 0" assertion on reconfigure (#1625)

Recent commit 0f78379 correctly removed an excessive cbdata lock of a
CachePeer::digest object in peerDigestCreate() but accidentally lost
another digest lock while inlining peerDigestCreate(). The resulting
excessive unlocking triggered reconfiguration assertions.

This change restores the lost lock as a short-term fix.

Long-term, CachePeer code should be fixed to become an exclusive[^1]
PeerDigest owner (i.e. creating and deleting its cbdata-protected digest
object without locking, unlocking, or checking locks). That improvement
is already in the works, but it requires significant code refactoring.

[^1]: Shared PeerDigest ownership (i.e. reference counting instead of
explicit delete and cbdata) does not work well in this context due to
circular references.
---

diff --git a/src/cache_cf.cc b/src/cache_cf.cc
index 1e570c4cbb..bd092e09cf 100644
--- a/src/cache_cf.cc
+++ b/src/cache_cf.cc
@@ -2402,8 +2402,10 @@ parse_peer(CachePeers **peers)
         p->connect_fail_limit = 10;
 
 #if USE_CACHE_DIGESTS
-    if (!p->options.no_digest)
-        p->digest = new PeerDigest(p);
+    if (!p->options.no_digest) {
+        const auto pd = new PeerDigest(p);
+        p->digest = cbdataReference(pd); // CachePeer destructor unlocks
+    }
 #endif
 
     if (p->secure.encryptTransport)