3 ms·

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

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.

nlewycky 3y ago
> 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/AddressSanitizerUseAfterReturn 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.com/en//pubs/archive/35604.pdf https://static.googleusercontent.com/media/research.google.c...

nlewycky 3y ago

> 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/AddressSanitizerUseAfterReturn 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.com/en//pubs/archive/35604.pdf https://static.googleusercontent.com/media/research.google.c...