Some applications use custom memory allocation functions. This can hide memory access bugs and prevent the detection of memory access errors. It may also practically disable the functionality of memory testing tools like Address Sanitizer.
It therefore often makes sense to disable custom memory allocators if possible. Sometimes this can be done by passing a configure option at compile time, sometimes it can be done via environment variables.
PHP: PHP has its own memory management as part of the Zend engine. It can be disabled by setting USE_ZEND_ALLOC=0 in the environment.
NSS: NSS and its underlying library NSPR use a custom memory allocation with so-called arenas. Setting NSS_DISABLE_ARENA_FREE_LIST=1 in the environment disables it.
Bash: The bash shell has its own memory allocation functions, they can only be configured/disabled at compile time. Passing --without-gnu-malloc to ./configure guarantees that the custom memory allocator gets disabled.
glib: The glib library, which is mainly used by many GTK+ and GNOME applications, provides a slice allocating feature that can hide memory safety violations. Setting the environment variable G_SLICE=always-malloc causes a single malloc call for each allocation. Setting G_SLICE=debug-blocks causes additional memory safety checks and is recommended for debugging. Future versions of glib will probably drop the slice allocator.
Browsers: Both Firefox and Chromium use custom memory allocators. They provide pre-built address sanitizer binaries (Chromium, Firefox) that can be used for testing and that already disable the custom memory allocators.
Apache/APR: Apache's APR library provides a custom pool allocator that can hide memory corruption issues. Unfortunately there is no way to turn it off. There used to be an option ALLOC_USE_MALLOC in Apache 2.0, but it has since been removed.
The Fuzzing Project is run by Hanno Böck