Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8

This page is a good high-level summary: http://code.google.com/p/address-sanitizer/wiki/ComparisonOf... .

I've used most of the tools on that page, including Valgrind. Valgrind interprets your program, and hooks loads, stores, malloc/free, etc. to track memory usage. ASan is a compiler pass that inserts extra instructions around loads and stores to drive per-address state machines that live in a shadow area of memory.

Valgrind is slow (20x-50x for serial programs, more for parallel programs because Valgrind only executes one thread at a time), but can detect reads from uninitialized memory because your program is essentially executing in a VM. ASan is much faster, especially if the compiler pass can avoid instrumenting some loads/stores based on static analysis, and cannot detect reads from uninitialized memory, but can detect most other kinds of memory areas.

They're both thread-safe, so you can use them to debug parallel programs. As mentioned above, Valgrind is much slower at this, and until recently [1] you would never see most race conditions in multithreaded programs because Valgrind's schedule would run each thread until it yielded voluntarily, rather than pre-empting and time-multiplexing between threads. In contrast, with ASan all threads are running close to at-speed and simultaneously, so in my case performance was >100x better and I actually saw the race conditions I cared about.

Valgrind supports more platforms than ASan (see [2] vs. [3]), and does not require compiler support (so you can use it to debug code from any compiler), but does tend to lag behind new platform features a bit. For example, until recently it borked if you used the new x86_64 RDTSCP instruction.

Mudflap seems similar in concept, but there appear to be issues with the implementation (see "Known Shortcomings" at [4])

[1] 3.8.0 and on have the --fair-sched=yes option http://valgrind.org/docs/manual/manual-core.html#manual-core... [2] http://valgrind.org/info/platforms.html [3] http://llvm.org/releases/3.1/tools/clang/docs/AddressSanitiz... [4] http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging

Long-time Valgrind user here, who has been using asan sporadically for a while inside Google. asan is way faster (and uses way less memory, I suspect), but is less exhaustive. Check out this page for more info: http://code.google.com/p/address-sanitizer/wiki/ComparisonOf...

Most notably, asan does not yet catch memory leaks, and will never be able to detect use of uninitialized values. Valgrind can tell you when you're using uninitialized values at bit-level granularity.

So Valgrind is still king in absolute capability, but it's likely that asan's speed will open it up to being used in cases where Valgrind simply isn't possible due to its speed/size overhead.

> If you are ... willing to accept a speed and memory hit (roughly factor of two) you could use ASAN in production

That's a pretty interesting idea, and seems to be a practical realization of something people have been trying to do for ages: produce a C variant with more safety. The most prominent project I know trying to do that is the C-like language Cyclone (http://cyclone.thelanguage.org/), but this seems like an alternate approach that lets you get "C but safer" without actually moving away from C.

Don't get me wrong; I don't mean to say it's not fantastic, just that the headline was misleading. My expectations for "Hey, we managed to move this stuff to compile time" is that it will be 1) more interesting theoretically, and 2) less interesting practically (at least in the short term). Either can be fantastic, and these expectations are sometimes violated besides, but I just wanted to give a heads up to others (at least, those that skim the HN comments first) or be corrected if my reading of it was wrong.

What you described is Thread Sanitizer (clang toolchain). The corresponding valgrind-based tools would be Helgrind and DRD.

ASan can only catch memory errors in C/C++ programs. A memory error is an access outside the allocated memory of an object, e.g. due to incorrect pointer arithmetics. Such errors would otherwise go undetected but can cause all kinds of errors in the program, like corrupted data, crashes etc.