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 5091f90)
Signed-off-by: Christopher Faulet <[email protected]>

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