There are four different consistency checks. The following corresponds to glibc 2.25.
- Various asserts. Whether they are active is determined when glibc is built. In the past, Debian and downstreams left asserts switched on. Fedora and downstreams disabled them in the past (but current Fedora leaves them on).
- Consistency checks in the core
malloc
implementation which do not use asserts, butmalloc_printerr
. In the past, they could be switched off usingMALLOC_CHECK_=0
(andmallopt
). However, the I doubt that the error recovery aftermalloc_printerr
is correct in all cases, so this is unlikely to work. And if there is heap corruption, the program might crash soon anyway. - Relatively lightweight heap buffer overflow detection. This is enabled by
MALLOC_CHECK_=3
(or another non-zero value). This cannot be switched on bymallopt
. It is implemented by increasing the size of allocations and storing some padding and checking it in some places. This heap checker should be thread-safe, and it is tightly coupled withmalloc
internals. However, it is rarely used, so there could easily be annoying bugs. - The
mcheck
function, called from__malloc_initialize_hook
by linking withlibmcheck.a
. This is completely different from the previous checks. I think the idea is to verify correct allocation behavior by having a separate set of metadata (independent of the actual allocator), andmcheck
does not depend on theglibc
malloc internals except for themalloc
hooks. However, its use of these hooks completely not thread safe. I don't think anyone usesmcheck
today. It is just included because no one has removed it yet. (It is not even needed for backwards compatibility because there is no guarantee that all heap corruption is detected, and applications which corrupt the heap are still completely undefined, so there is no way to detect whethermcheck
actually performs additional checks.)
In addition to that, there is also MALLOC_PERTURB_
, which can be used to detect some forms of access to uninitialized or freed data.