Another way to do similar run-time analysis is with valgrind (valgrind.org). valgrind doesn't require the code to be instrumented beforehand, which can be good or bad, depending.
The fact that code must be instrumented for ASAN is actually quite handy in some cases -- for instance, we run C++ code in the JVM. Running that whole thing under valgrind is quite slow, and we've had to develop our own tools to suppress all the superfluous warnings that have nothing to do with our code. With ASAN the same tests run much more quickly and we're only testing code that we can actually fix.
A couple of things that may be of interest:
ASAN is also part of gcc since version 4.8, although gcc support tends to lag somewhat behind (see btorpey.github.io/blog/2014/03/27/... for more).
Another way to do similar run-time analysis is with valgrind (valgrind.org). valgrind doesn't require the code to be instrumented beforehand, which can be good or bad, depending.
The fact that code must be instrumented for ASAN is actually quite handy in some cases -- for instance, we run C++ code in the JVM. Running that whole thing under valgrind is quite slow, and we've had to develop our own tools to suppress all the superfluous warnings that have nothing to do with our code. With ASAN the same tests run much more quickly and we're only testing code that we can actually fix.
I like that idea of running all tests with Asan. It's pretty radical, but it would definitely be a strong enforcement of code quality standards.
I've been doing this for a while in my networking code, all tests are built and run with asan active always.
The overhead is quite negligible even if I do audio I/O.
Agreed. I had actually forgotten to disable the address sanitizer yesterday while debugging something else, and I didn't even notice the slow-down.