3 ms·
valgrind is really essential. Just about every C project that I have written has a "make check-valgrind" rule which runs the same set of tests as "make check",
by rwmj 3y ago
valgrind is really essential. Just about every C project that I have written has a "make check-valgrind" rule which runs the same set of tests as "make check", but under valgrind. Passing both is a requirement for release (although for various reasons to do with cost, only "make check" is done in CI).
valgrind mainly finds memory leaks, buffer overflows and use of unintialized memory. It even works relatively well with some non-C languages.
Example:
https://gitlab.com/nbdkit/nbdkit/-/blob/9f96d53dbbbf67ae5ed0acb2ef8887709c47d3cc/tests/Makefile.am#L159-L161 https://gitlab.com/nbdkit/nbdkit/-/blob/9f96d53dbbbf67ae5ed0...
- gpderetta 3y agoValgrind was quite essential, but these days the various sanitizers are both easier to integrate, faster and catch more issues.
- adrianN 3y agoDo they catch more issues? I thought valgrind was the gold standard. I would be happy to be proven wrong!
- PhilipRoman 3y agoIts a tradeoff, they both specialize for slightly different situations. Sanitizers have intricate knowledge of what is undefined behavior at a source level. For example signed integer overflow, etc. Some of these are simply not possible to determine at runtime, as a valid C program is allowed to generate the same machine code as one containing UB. Valgrind, on the other hand, cares purely about the machine code (with a few exceptions like malloc, free, etc.). It can peek into your libraries even if they aren't compiled with sanitizer flags. It is especially good for finding uninitialized memory usage - IIRC it can track this data even on the level of individual bits in a register.