Both of those are very useful, but slow, especially valgrind.
I don't know OpenBSD, but presumably this is analogous to glibc's relatively faster memory sanity checking.
For GCC and clang you'd also want LSAN for this, not ASAN. ASAN is more accurate for edge cases, but much slower.
"Slow" here means that even for development the runtime can be prohibitively expensive.
E.g. I regularly run git's test suite, optimized/LSAN/ASAN/valgrind runtime is on the order of 3m/15m/30m/24 hours. The basic glibc sanity checking only adds a minute or two to the optimized run.
An advantage of any malloc based detection is also that you can run it on any existing binary. Whereas the likes of LSAN and ASAN require a custom debugging build (or to have that tracing overhead present in your production build).
I don't know OpenBSD, but presumably this is analogous to glibc's relatively faster memory sanity checking.
For GCC and clang you'd also want LSAN for this, not ASAN. ASAN is more accurate for edge cases, but much slower.
"Slow" here means that even for development the runtime can be prohibitively expensive.
E.g. I regularly run git's test suite, optimized/LSAN/ASAN/valgrind runtime is on the order of 3m/15m/30m/24 hours. The basic glibc sanity checking only adds a minute or two to the optimized run.
An advantage of any malloc based detection is also that you can run it on any existing binary. Whereas the likes of LSAN and ASAN require a custom debugging build (or to have that tracing overhead present in your production build).