Avoid creating unlocked store_table entries when handling rebuild conflicts.

Such StoreEntry objects persist until a hit locks and unlocks them (or the
replacement policy removes them?), creating SMP synchronization problems
because they are treated as in-transit objects even though their store slot
may be gone already.

diff --git a/src/store_rebuild.cc b/src/store_rebuild.cc
index 26045beecfe2f256c6d521e730e5e6bbb75ec45c..0ae8ef17805a68ff4c1c1bce7327091a3af45d5f 100644 (file)
--- a/src/store_rebuild.cc
+++ b/src/store_rebuild.cc
@@ -400,6 +400,12 @@ storeRebuildKeepEntry(const StoreEntry &tmpe, const cache_key *key,
             /* key already exists, old entry is newer */
             /* keep old, ignore new */
             counts.dupcount++;
+
+            // For some stores, get() creates/unpacks a store entry. Signal
+            // such stores that we will no longer use the get() result:
+            e->lock();
+            e->unlock();
+
             return false;
         } else {
             /* URL already exists, this swapfile not being used */