Unexpected partial use of jemalloc by BIND (tested on 9.18.19-S1)

Summary

As reported in case SF#1428:

====

I've been trying to use jemalloc to build BIND 9.18.x, and noticed something bit awkward that might not be intentional.

I've manually installed jemalloc 5.3.0, and then built BIND 9.18.19-S1 with --with-jemalloc (which shouldn't be necessary but I wanted to make it explicit). It's indeed linked with libjemalloc:

root@c45a8371918a:/tmp/bind-9.18.19-S1# ldd bin/named/.libs/named
linux-vdso.so.1 (0x00007ffcb6bfe000)
libisc-9.18.19-S1.so => /usr/local/lib/libisc-9.18.19-S1.so (0x00007f6052fc6000)
libdns-9.18.19-S1.so => /usr/local/lib/libdns-9.18.19-S1.so (0x00007f6052b9f000)
libns-9.18.19-S1.so => /usr/local/lib/libns-9.18.19-S1.so (0x00007f605294e000)
libisccc-9.18.19-S1.so => /usr/local/lib/libisccc-9.18.19-S1.so (0x00007f6052745000)
libisccfg-9.18.19-S1.so => /usr/local/lib/libisccfg-9.18.19-S1.so (0x00007f605250f000)
libbind9-9.18.19-S1.so => /usr/local/lib/libbind9-9.18.19-S1.so (0x00007f60522f8000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f6051e2d000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f6051c27000)
libuv.so.1 => /usr/lib/x86_64-linux-gnu/libuv.so.1 (0x00007f6051a01000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f60517e4000)
libjson-c.so.3 => /lib/x86_64-linux-gnu/libjson-c.so.3 (0x00007f60515d9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f60513ba000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6050fc9000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6050dc1000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f6050b34000)
libjemalloc.so.2 => /usr/local/lib/libjemalloc.so.2 (0x00007f6050675000)
[...]

I then confirmed the call to malloc() in isc__trampoline_attach is the one defined in the standard libc (see the attached file). That seems to defeat the intent of this malloc call described in the comment:

/*
* Ensure every thread starts with a malloc() call to prevent memory
* bloat caused by a jemalloc quirk. While this dummy allocation is
* not used for anything, free() must not be immediately called for it
* so that an optimizing compiler does not strip away such a pair of
* malloc() + free() calls altogether, as it would foil the fix.
*/

I suspect this is because libc is seemingly loaded before libjemalloc (as shown in the above ldd output), and so libc's malloc is first found and used. isc_mem_xxx still uses jemalloc since it calls jemalloc's custom functions. Also, if I set LD_PRELOAD to /usr/local/lib/libjemalloc.so to run named, malloc defined in jemalloc is used in isc__trampoline_attach (and apparently anywhere else).

Now my question is: is this behavior intentional? I'm actually planning to set LD_PRELOAD for some other reasons, but if the current behavior is intentional (i.e., using libc's malloc/free etc for anywhere else than isc_mem_xxx), is there a reason why I "should not" set LD_PRELOAD?

BIND version used

9.18.19-S1

Steps to reproduce

See above

What is the current bug behavior?

See above

What is the expected correct behavior?

See above

Relevant configuration files

See above

Relevant logs and/or screenshots

See above

Possible fixes

See above