Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8
1–10 of 28 posts
Re: Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8
#2Have these patches been accepted? From the mailing list thread, it looks like there are still some minor issues to work through, and I wasn't able to get a sense of whether the mainline committers wanted to do this or not. The fact that it's been in Clang+compiler-rt mainline for a while, and has been supported, should be a point in their favor.
ASan works great! To save you a bit of effort in figuring out how it works, this is the best source I found (besides the source): https://www.usenix.org/system/files/conference/atc12/atc12-f...
Re: Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8
#3"Compile-time valgrind" seems incorrect. It is compile-time addition of run-time valgrind-like instrumentation.
Re: Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8
#4Have these patches been accepted? From the mailing list thread, it looks like there are still some minor issues to work through, and I wasn't able to get a sense of whether the mainline committers wanted to do this or not. The fact that it's been in Clang+compiler-rt mainline for a while, and has been supported, should be a point in their favor. ASan works great! To save you a bit of effort in figuring out how it wor…
Do you have experience with valgrind? Can you compare & contrast the two?
Also, I thought that the compiler additions was implemented years ago, several times (tristan gingold's "checker-gcc" first, then the bounds-checking patches and most recently "-fmudflap"), so that asan's functionality would basically only require rewriting libmudflap - but it apparently requires a much deeper surgery of gcc. Can anyone familiar with asan and/or the previous implementations comment on that?
Re: Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8
#5"Compile-time valgrind" seems incorrect. It is compile-time addition of run-time valgrind-like instrumentation.
Yeah, it's not static analysis... it's runtime instrumentation. And BTW it's very useful and helped me find a race condition.
Re: Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8
#6As a person unfamiliar with the concepts presented in the OP, I would not mind if someone explained its significance in layman's terms.
Re: Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8
#7Have these patches been accepted? From the mailing list thread, it looks like there are still some minor issues to work through, and I wasn't able to get a sense of whether the mainline committers wanted to do this or not. The fact that it's been in Clang+compiler-rt mainline for a while, and has been supported, should be a point in their favor. ASan works great! To save you a bit of effort in figuring out how it wor…
Do you have experience with valgrind? Can you compare & contrast the two? Also, I thought that the compiler additions was implemented years ago, several times (tristan gingold's "checker-gcc" first, then the bounds-checking patches and most recently "-fmudflap"), so that asan's functionality would basically only require rewriting libmudflap - but it apparently requires a much deeper surgery of gcc. Can anyone familia…
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
Re: Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8
#8"Compile-time valgrind" seems incorrect. It is compile-time addition of run-time valgrind-like instrumentation.
Yes, that's right. It does do the same thing as valgrind but the practical benefit of compile-time instrumentation rather than dynamic translation is that ASAN is enormously faster.
A lot of people are using this on their fuzzing rigs with large software applications like Firefox. ASAN hugely decreases cost per test cycle (and therefore cost per bug, without changing fuzzers).
A friend and I chipped in to get a fuzz server (quad xeon X5660, 96 GB RAM, dual SSD). It's paid for itself twice over in bug bounties and there are more in the queue. Valgrind was always too expensive but using ASAN builds we can find more bugs.
Having ASAN support in GCC would be really handy, because for large projects it can be a major effort to get everything to compile in CLANG.
If you are sufficiently paranoid, and willing to accept a speed and memory hit (roughly factor of two) you could use ASAN in production. Personally, I am beginning to entertain the idea of using an ASAN-instrumented browser for day-to-day use.
Re: Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8
#9Nice! Didn't know there was work to add ASan to gcc too.
ASan is already in Clang[1], and I've heard some of rumours of a ‘Thread Sanitizer’ as well. All kinds of interesting projects brewing inside of google, it seems :)
[1] http://llvm.org/releases/3.1/docs/ReleaseNotes.html#whatsnew
Re: Google Address Sanitizer ("compile-time valgrind") to be part of GCC 4.8
#10"Compile-time valgrind" seems incorrect. It is compile-time addition of run-time valgrind-like instrumentation.
Yes, that's right. It does do the same thing as valgrind but the practical benefit of compile-time instrumentation rather than dynamic translation is that ASAN is enormously faster. A lot of people are using this on their fuzzing rigs with large software applications like Firefox. ASAN hugely decreases cost per test cycle (and therefore cost per bug, without changing fuzzers). A friend and I chipped in to get a fuzz…
> 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.