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). (cherry picked from commit 5091f90479ab4d963b55cb725cee8201d93521d9) Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This commit is contained in:
parent
a6ecd879b1
commit
27ade1e5fe
@ -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];
|
||||
}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user