Valgrind recieves a development microgrant from FUTO | Hacker News Reader

Valgrind recieves a development microgrant from FUTO

fosstodon.org

90 pointspabs323 comments

Maybe they can finally merge my 10 year old patch /s

https://bugs.kde.org/show_bug.cgi?id=290061

Might be worth rebasing it on the current codebase and sending a new patch update.

So what's a microgrant? On futo.org I can find only some links for legendary grants, which I guess isn't micro.

As far as I understand it, microgrants are given out every month by people within FUTO, as a thank-you to software... that is used by people withing the organization. From the video they did in May, I think those grants are about $1000.

What is the use case for valgrind vs memory sanitizer?

valgrind does far more than asan-like analysis. --tool=callgrind for instance

Valgrind is like all the sanitizers (memory, thread, leak, address, undefined) all together, plus performance and memory profilers, all for uninstrumented code.

For me the real key is the last part. If you're happy building and testing with sanitizers from source, I don't think there's much more to gain by adding Valgrind to the mix, but if sanitizers aren't available or you find yourself with a binary and not source, I'd check out Valgrind.

> Valgrind is like all the sanitizers (memory, thread, leak, address, undefined) all together, plus performance and memory profilers, all for uninstrumented code.

Valgrind as memcheck can do memory and leak and partially do address sanitizer, and when run as helgrind can do thread sanitizer. Valgrind doesn't do -fsanitize=undefined.

Undefined -- UBSan -- in particular doesn't overlap with valgrind. Your CPU uses the same instructions for signed and unsigned integer addition (thanks to 2's complement) but UBSan will catch signed integer overflow. UBSan will catch misaligned pointers whether the CPU permits unaligned accesses or not. UBSan will catch integer and float divide by zero, which valgrind ignores because at the CPU level those have defined behaviours (of setting an error flag or whatnot).

As for partially doing address sanitizer, ASan improves its probability of catching invalid pointer arithmetic by intentionally spacing out stack allocations and global variables in a way that the compiler is allowed to do but which valgrind can't because valgrind has to emulate the CPU instructions as they lie. ASan also replaces malloc with its own version that attempts to give different addresses as much as possible so that the use of a freed pointer is maximally likely to not accidentally point to memory which has since been reallocated.

Optionally ASan also includes special features like "after running the inliner, malloc a fresh stack for every function call" so that you can really catch stack use after return https://github.com/google/sanitizers/wiki/AddressSanitizerUs...

I'm not deeply familiar with either ThreadSanitizer or Helgrind. The TSan devs claim that Helgrind either runs in "catches too few bugs" mode or "has too many false positives" mode and that they got it just right in TSan. I can't evaluate that claim. https://static.googleusercontent.com/media/research.google.c...

Valgrind works on arbitrary code. Even if it's doing things like jit compilation or self modifying code. Without requiring the compiler to have injected instrumentation ahead of time.

There's a lot of C I've written which is only correct because I ran the test suite under valgrind while implementing it.

It can detect more errors and you don't need to recompile anything.

Generally asan+msan detect more errors, and some quite significant ones. For design reasons, valgrind cannot detect most stack oob bugs. The only issue with msan is that it's a bit trickier to use, particularly if you have lots of dependencies.

Both approaches have their right to exist, but I have been preaching to people that valgrind does not find all memory safety bugs that modern tools can find, and they should be testing with sanitizers. I still experience that many people are not aware of asan+co and only know valgrind.

How well does ASAN cope when the libraries your application uses aren't compiled with ASAN? Does it cause false negatives or false positives?

ASan will have false negatives on the memory accesses performed in the code which isn't compiled with ASan. It works fine, otherwise. FWIW, UBSan (-fsanitize=undefined) follows the same rule. For this reason it's common to combine them and build once with -fsanitize=address,undefined. Don't forget to pass that while linking too.

ThreadSanitizer requires that all code with atomic accesses be instrumented.

MemorySanitizer requires that all code which writes to a byte in memory be instrumented.

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.

What 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.

It could probably catch some leaks. Rust doesn't make you immune to leaked memory.

I 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.

In 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.

> 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.

Except 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.

Having separate debug and release targets is hardly new.

And 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.

I've always thought that valgrind is one the most metal names for a piece of software.

Valgrind, the gate to Valhalla. And Valhalla, the hall of the dead. Very appropriate name given what this piece of software does.

Reply on news.ycombinator.com