]> git.ipfire.org Git - thirdparty/squid.git/commitdiff
Annotate PoolMalloc memory in valgrind builds (#1946)
authorAlex Rousskov <rousskov@measurement-factory.com>
Wed, 13 Nov 2024 18:16:08 +0000 (18:16 +0000)
committerSquid Anubis <squid-anubis@squid-cache.org>
Wed, 13 Nov 2024 22:20:46 +0000 (22:20 +0000)
MemPoolMalloc code (i.e. memory_pools code used by default) was missing
VALGRIND_MAKE_MEM_*() calls. Similar calls do exist in MemPoolChunked
code (i.e. code enabled by setting MEMPOOLS environment variable to 1).

Even with these markings, "memory_pools on" configuration is still not
quite compatible with Valgrind leak reporting suppressions: In some
cases, Valgrind may still incorrectly suppress leak reporting (or report
leaks that should have been suppressed) because Valgrind associates leak
suppressions with memory _allocators_ while buggy code may leak memory
allocated by others. The long-term solution (if it exists) requires
upgrading these markings to VALGRIND_MEMPOOL_*() API targeting memory
pools, but that requires a serious effort, especially when dealing with
MemPoolChunked complexities. The added markings help detect non-leak
violations and improve PoolMalloc/MemPoolChunked code symmetry.

src/mem/PoolMalloc.cc

index 7a33eab94cb6e4d72a6e540fe50acdc389c8a821..d361f4b5c22791547630a761ade6f85a169f4811 100644 (file)
@@ -31,6 +31,10 @@ MemPoolMalloc::allocate()
     if (obj) {
         --meter.idle;
         ++countSavedAllocs;
+        if (doZero)
+            (void)VALGRIND_MAKE_MEM_DEFINED(obj, objectSize);
+        else
+            (void)VALGRIND_MAKE_MEM_UNDEFINED(obj, objectSize);
     } else {
         if (doZero)
             obj = xcalloc(1, objectSize);
@@ -52,6 +56,7 @@ MemPoolMalloc::deallocate(void *obj)
     } else {
         if (doZero)
             memset(obj, 0, objectSize);
+        (void)VALGRIND_MAKE_MEM_NOACCESS(obj, objectSize);
         ++meter.idle;
         freelist.push(obj);
     }