Use Case: Find a memory corruption bug

[Note: starting from jemalloc 5.0, valgrind integration has been removed. Please still consider AddressSanitizer and Valgrind first (jemalloc-incompatible) for memory corruption investigations.] If possible, really consider using the excellent valgrind tool for memory debugging. If for some reason valgrind won't work for you (e.g. it is too slow or uses too much memory), there are some basic features in jemalloc that may be of some help.

If jemalloc is configured with --enable-debug specified, various assertions are compiled in that can detect double frees, misaligned pointers, etc. These checks are unnecessary for correctly functioning applications, but they can be helpful during development. One caveat is that many of the assertions relate to arena data structures, but thread caching can prevent arena-related assertions from running in a timely fashion. Disabling thread caching (MALLOC_CONF=tcache:false) tends to make jemalloc's internal assertions much more effective at catching application errors, especially double frees.

If jemalloc is configured with --enable-fill specified, you can set MALLOC_CONF=junk:true in the environment to tell malloc() to fill objects with 0xa5 bytes, and free() to fill freed memory with 0x5a bytes. It is quite common for an application to accidentally get zeroed memory from malloc(), which can hide bugs due to missing initialization code. Another common mistake is to access an object after it has been freed. If your application behaves differently with the junk:true option specified, there's a bug in the code somewhere. Similarly, if the problem is intermittent, and MALLOC_CONF=zero:true makes the problem go away, your application probably depends on getting zeroed memory from malloc().