2 ms·
Valgrind is super-practical because you can use it on any existing binary. Basically every project I'm involved in has a "make check-valgrind" rule which runs
by rwmj 3y ago
Valgrind is super-practical because you can use it on any existing binary. Basically every project I'm involved in has a "make check-valgrind" rule which runs all the unit tests again, but under valgrind. It has caught countless memory leaks (mainly) and memory errors. We also run it on Rust, OCaml and Perl code.
- unmole 3y ago> Basically every project I'm involved in has a "make check-valgrind" rule This the exact scenario where address sanitizer makes more sense. I stopped using Valgrind because ASan catches more issues, doesn't report false positives and is much much faster.
- rwmj 3y agoExcept you have to recompile everything so you're not testing the same binaries that you're going to ship. That's exactly the reason to use valgrind.
- unmole 3y agoHaving separate debug and release targets is hardly new.
- rwmj 3y agoAnd is still a terrible idea. I build everything with debugging symbols (albeit in a separate debuginfo downloadable), and debug messages can be turned on at any time. Saved my bacon countless times in production environments.
- er4hn 3y agoWhat does it catch under Rust? Unsafe code? I'm under the impression the borrow checker would prevent the class of problems valgrind is made for.
- pornel 3y agoIn Rust it would catch the same kinds of buffer overflows and UAFs, but these rarely sneak past the compiler. However, it's handy for testing Rust wrappers for C libraries, because the FFI/ABI boundary is fragile and inherently unsafe.
- dralley 3y agoIt could probably catch some leaks. Rust doesn't make you immune to leaked memory.
- rwmj 3y agoI don't recall valgrind catching anything in Rust code right now, but do remember that we're binding to C libraries so it's still possible for them to leak; or as you say something inside an unsafe clause.