]> 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)
committerAmos Jeffries <yadij@users.noreply.github.com>
Sat, 16 Nov 2024 00:07:13 +0000 (13:07 +1300)
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 bf3afeaadb6ae4e9f6798aece6dbdb8d10ad4c82..9e3fcb03d56199f53bc4803a1d7ce390a2dd3f0b 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);
     }