MINOR: activity/memprofile: always return "other" bin on NULL return address
authorWilly Tarreau <w@1wt.eu>
Tue, 15 Oct 2024 06:09:09 +0000 (08:09 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Wed, 23 Oct 2024 15:25:12 +0000 (17:25 +0200)
commit27ade1e5fe2a715215164f63e5b219dbe54a17c6
tree8b386caf79a96c0a057eb21a6facbf6a06a315a1
parenta6ecd879b1b30a458294f843e12e4459080996e0
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>
src/activity.c