From 4657405c4afd8d7125f747b5351f60844815af09 Mon Sep 17 00:00:00 2001 From: Eduard Bagdasaryan Date: Mon, 25 Dec 2023 02:20:19 +0000 Subject: [PATCH] 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. --- src/cache_cf.cc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) 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) -- 2.39.5