Investigate running tests under Address Sanitizer

[jdm]

http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer

It finds use-after-free and out-of-bounds errors with very little overhead. Could be useful.

[sayrer]

On OS X, you can use libgmalloc. It isn't that slow.

[brson]

I agree this looks really cool. Needs compiler support.

[graydon]

nominating for well covered

[graydon]

subset of valgrind, doesn't improve accuracy, de-milestoning

[graydon]

just a bug, removing milestone/nomination.

[bblum]

Ah, this is clever. They beat valgrind because they add instrumentation into the code while it's being compiled, rather than preloading stuff at runtime. For our purposes this is fine; since we have a dedicated set of valgrind bots, they can just do make ASAN=1 or whatever from the start.

(Triage visit in disguise.)

[bblum]

By the way, the paper is clearly-written and pretty approachable.

[huonw]

Triage: not done yet.

[vadimcn]

cc #8426

[emberian]

To compile with asan:

rustc --passes asan,asan-module --link-args "/usr/bin/../lib/clang/3.4/lib/linux/libclang_rt.asan-x86_64.a" foo.rs

[emberian]

https://mail.mozilla.org/pipermail/rust-dev/2014-February/008521.html

[emberian]

If we start building the libclang_rt stuff, it'd be trivial to add a --sanitize option to rustc.

[vadimcn]

To catch bad memory accesses (e.g. use after free) Rust will need to start emitting sanitize_address attribute on all functions, though. Otherwise asan passes won't insert any instrumentation.

[emberian]

Ah good to know. That shouldn't be hard at all though.

On Tue, Feb 4, 2014 at 3:58 AM, Vadim Chugunov notifications@github.comwrote:

To catch bad memory accesses (e.g. use after free) Rust will need to start
emitting sanitize_address attribute on all functions, though. Otherwise
asan passes won't insert any instrumentation.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/749#issuecomment-34040924
.

[thestinger]

This really needs to be refiled as "implement address sanitizer support" which is a huge project. It's not useful without frontend support, and IMO it's too much complexity to add to librustc in the current state it's in. Sanitizers would need to be added for all the unsafe intrinsics along with unsafe pointer dereferencing. It's not going to map well to the sanitizers used by Clang, since Rust does everything in the libraries with the basic compiler intrinsics. It doesn't have a language feature for unsafe indexing of arrays, etc.