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).
This commit is contained in:
Willy Tarreau 2024-10-15 08:09:09 +02:00
parent 93c9f19af7
commit 5091f90479
1 changed files with 5 additions and 0 deletions

View File

@ -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];
}