From 5091f90479ab4d963b55cb725cee8201d93521d9 Mon Sep 17 00:00:00 2001 From: Willy Tarreau Date: Tue, 15 Oct 2024 08:09:09 +0200 Subject: [PATCH] MINOR: activity/memprofile: always return "other" bin on NULL return address It was found in a large "show profiling memory" output that a few entries have a NULL return address, which causes confusion because this address will be reused by the next new allocation caller, possibly resulting in inconsistencies such as "free() ... pool=trash" which makes no sense. The cause is in fact that the first caller had an entry->info pointing to the trash pool from a p_alloc/p_free with a NULL return address, and the second had a different type and reused that entry. Let's make sure undecodable stacks causing an apparent NULL return address all lead to the "other" bin. While this is not exactly a bug, it would make sense to backport it to the recent branches where the feature is used (probably at least as far as 2.8). --- src/activity.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/activity.c b/src/activity.c index 5417deb62..c38deed08 100644 --- a/src/activity.c +++ b/src/activity.c @@ -185,6 +185,10 @@ struct memprof_stats *memprof_get_bin(const void *ra, enum memprof_method meth) const void *old; unsigned int bin; + if (unlikely(!ra)) { + bin = MEMPROF_HASH_BUCKETS; + goto leave; + } bin = ptr_hash(ra, MEMPROF_HASH_BITS); for (; memprof_stats[bin].caller != ra; bin = (bin + 1) & (MEMPROF_HASH_BUCKETS - 1)) { if (!--retries) { @@ -199,6 +203,7 @@ struct memprof_stats *memprof_get_bin(const void *ra, enum memprof_method meth) break; } } +leave: return &memprof_stats[bin]; }