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 1e570c4cbba2d1ee4e811499acb73471c7fa1636..bd092e09cf1dc40e12279a35f0fedae85e995f6b 100644 (file)
--- 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)