Instead of reporting the inaccurate "malloc_trim() support" on -vv, let's report the case where the memory allocator was actively replaced from the one used at build time, as this is the corner case we want to be cautious about. We also put a tainted bit when this happens so that it's possible to detect it at run time (e.g. the user might have inherited it from an environment variable during a reload operation). The now unused is_trim_enabled() function was finally dropped.
This way it will be usable from outside instead of malloc_trim().
As reported by Miroslav in commit d8a97d8f6 ("BUG/MINOR: illegal use of
the malloc_trim() function if jemalloc is used") there are still occasional
cases where it's discovered that malloc_trim() is being used without its
suitability being checked first. This is a problem when using another
incompatible allocator. But there's a class of use cases we'll never be
able to cover, it's dynamic libraries loaded from Lua. In order to address
this more reliably, we now define our own malloc_trim() that calls the
previous one after checking that the feature is supported and that the
allocator is the expected one. This way child libraries that would call
it will also be safe.
The function is intentionally left defined all the time so that it will
be possible to clean up some code that uses it by removing ifdefs.
In the event that HAProxy is linked with the jemalloc library, it is still shown that malloc_trim() is enabled when executing "haproxy -vv": .. Support for malloc_trim() is enabled. .. It's not so much a problem as it is that malloc_trim() is called in the pat_ref_purge_range() function without any checking. This was solved by setting the using_default_allocator variable to the correct value in the detect_allocator() function and before calling malloc_trim() it is checked whether the function should be called.
The same change was already performed for the cli. The stats applet and the prometheus exporter are also concerned. Both use the stats API and rely on pool functions to get total pool usage in bytes. pool_total_allocated() and pool_total_used() must return 64 bits unsigned integer to avoid any wrapping around 4G. This may be backported to all versions.
There's no need for the low-level pool functions to be known from all callers anymore, they're only used by pool.c. Let's reduce the amount of header files processed.
The "show pools" command is used a lot for debugging but didn't get much
love over the years. This patch brings new capabilities:
- sorting the output by pool names to ese their finding ("byname").
- sorting the output by reverse item size to spot the biggest ones("bysize")
- sorting the output by reverse number of allocated bytes ("byusage")
The last one (byusage) also omits displaying the ones with zero allocation.
In addition, an optional max number of output entries may be passed so as
to dump only the N most relevant ones.
This macro just serves as an intermediary for __pool_alloc() and forwards the flag. When DEBUG_MEM_STATS is set, it will be used to collect all pool allocations including those which need to pass an explicit flag. It's now used by b_alloc() which previously couldn't be tracked by DEBUG_MEM_STATS, causing some free() calls to have no corresponding allocations.
HA_WEAK() is supposed to take a symbol in argument, not a string, since the asm statements it produces already quote the argument. Having it quoted twice doesn't work on older compilers and was the only reason why DEBUG_MEM_STATS didn't work on older compilers.
The memstats code currently defines its own file/function/line number, type and extra pointer. We don't need to keep them separate and we can easily replace them all with just a struct ha_caller. Note that the extra pointer could be converted to a pool ID stored into arg8 or arg32 and be dropped as well, but this would first require to define IDs for pools (which we currently do not have).