Btw, the most efficient way for catching memory bugs would be disabling memory arenas completely. That would result in the best instrumentation out of the box. But sadly it's not possible with current code which never calls dummy free()/delete for arena allocations.

features must be auto-disabled, if they don't work together. ASAN and safemalloc do.

If you want ASAN without safemalloc, you do -DWITH_ASAN=ON -DWITH_SAFEMALLOC=OFF.

TRASH_FILL() starts from MEM_UNDEFINED(), so TRASH_ALLOC is
MEM_UNDEFINED(A,B); memset(A,B,0xA5); MEM_UNDEFINED(A,B); which is good both for ASAN and Valgrind.

Same for TRASH_FREE.

And if you want it to be just MEM_NOACCESS, you compile without debugging but with ASAN.

Well, it's a bit coarse-grained.

Here is the PR https://github.com/MariaDB/server/pull/569

kevg, sorry, I did not realize that you had updated your contribution last night.
I ended up doing something similar, just a bit more in order not to break UNIV_MEM_DEBUG (which admittedly is of little use) or Valgrind. With my changes, also with Valgrind, we will flag the address ranges unaccessible as early as possible.

What remains to be done (once the code has been merged from 5.5 up to 10.2) is to add the address range poisoning to the transaction Pool. I believe that it should work with both ASAN and Valgrind.
There will be some limitations for Valgrind, because apparently Valgrind discards the metadata on which bits are initialized when access to the address range is disabled. But I believe that we can address that by adding some UNIV_MEM_VALID to ‘initialize’ those fields that are supposed to remain initialized while the transaction objects are in the freed state.

I added poisoning to the Pool of trx_t, which was introduced via MySQL 5.7 to MariaDB 10.2.2. This revealed that innodb_monitor is accessing trx_t::mutex and trx_t::undo_mutex even for freed trx_t objects.
With this instrumentation, I think that all dynamically managed memory is reasonably well poisoned.