Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gcc.gnu.org

Post reply on HN
Print view View original

21–28 of 28 posts

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

#21

Post by haberman »

beagle3 wrote: post #4
sparky wrote: post #2

Have 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…

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.

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

#22

Post by ThomasQue »

One advantage of Valgrind over Address Sanitizer is that you're not limited to checking C/C++ programs. For example I am developping a programming language for fun and I can check for bad memory usages using Valgrind. From what I understand, that wouldn't be possible with Google's tool.

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

#23

Post by nostrademons »

haberman wrote: post #21
beagle3 wrote: post #4

Earlier quoted context omitted.

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…

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'…

You're probably using ASAN a lot more than sporadically within Google. A lot of the continuous builds run with it on.

I think that's really the biggest advantage ASAN has - it's cheap enough that you can just make it the default when running tests or developing on your local machine, and catch a number of memory errors immediately instead of having to actively debug them.

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

#24

Post by pcwalton »

_delirium wrote: post #10
xyzzy123 wrote: post #8

Earlier quoted context omitted.

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…

We're also trying to do that with Rust (it's based on the work of Dan Grossman and others with the Cyclone region-based memory management). It depends on whether you consider it a C variant, of course.

Cyclone is something every programming language enthusiast should look into, IMHO. It's extremely interesting, well-done work.

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

#27

Post by andrewcooke »

sparky wrote: post #19
nnethercote wrote: post #17

Earlier quoted context omitted.

> Valgrind interprets your program No, it has a JIT. It's running compiled code. See http://valgrind.org/docs/valgrind2007.pdf for details, section 3 in particular.

You're right (and you should know!), my mistake. I knew it too, and just mistyped. I would edit the post above if I could.

and is it still 20-50x slower? i haven't done measurements, but it feels like a factor of 2 or 3 these days, to me (single threaded).

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

#28

Post by xyzzy123 »

chacham15 wrote: post #26

Is there any chance in the future of this working on Windows?

See: http://code.google.com/p/address-sanitizer/wiki/WindowsPort for info on Clang and ASan.

Will probably see GCC 4.8 on Windows before Clang++ and ASan.

Post reply on HN