5 ms·

I like Valgrind, but day-to-day, I find myself typically reaching for Sanitizers[1] instead (ASan, et. al.), especially since they're built-in to many compilers

I like Valgrind, but day-to-day, I find myself typically reaching for Sanitizers[1] instead (ASan, et. al.), especially since they're built-in to many compilers these days, and are a bit faster IME. Are there any use cases that people here have experienced where Valgrind is their first choice? [1] https://github.com/google/sanitizers https://github.com/google/sanitizers

synergy20 2y ago
same here, also for embedded systems valgrind is too heavy to run natively
lbrandy 2y ago
For uninitialized memory reads, which is one of the biggest classes of issues, valgrind can still be invaluable. MSAN is one of the more difficult things to get setup and remove all the false positives. You typically need to transitively compile everything including dependencies, or annotate/hint lots of things to get the signal-to-noise ratio right. Sometimes its just easier/better/faster to run it under valgrind.
patrick451 2y ago
IME, sanitizer don't find enough issues compared valgrind, and valgrind doesn't require me to recompile the world. If I have anything that feels like UB, especially that I can trigger in a unit test, I run it through valgrind first. If the issue can only be triggered by running the whole system and valgrind slows it down too much, there's a good chance that sanitizers will also slow it down too much.
nickelpro 2y ago
Callgrind is indispensable for performance profiling and has no compiler-based equivalents
- Sesse__ 2y ago
  Callgrind is certainly dispensable; just use a profiler. They are much, much faster, and more accurate as well. (Callgrind is using an idealized model of CPUs as they were around 1995, which doesn't match up all that well with how they work today.) There are some situations where I find myself using Callgrind, in particular in situations where stack traces are hard to extract using a regular profiler. But overall, it's a tool that I find vastly overused.
  - dennis_moore 2y ago
    Which profilers in particular are you referring to because I've always thought that Callgrind is a profiler? perf?
    - rwmj 2y ago
      perf on the whole system, with the whole software stack compiled with stack pointers, flamegraphs for visualisation, is an essential starting point for understanding real world performance problems.
    - Sesse__ 2y ago
      perf or Intel VTune are the two standard choices AFAIK. Both have a certain learning curve, both are extremely capable in the right hands. (Well, on macOS you're pretty much locked to using Instruments; I don't know if Callgrind works there but would suspect it's an uphill battle.) Callgrind is a CPU simulator that can output a profile of that simulation. I guess it's semantics whether you want to call that a profiler or not, but my point is that you don't need a simulator+profiler combo when you can just use a profiler on its own. (There are exceptions where the determinism of Callgrind can be useful, like if you're trying to benchmark a really tiny change and are fine with the bias from the simulation diverging from reality, or if you explicitly care about call count instead of time spent.)
  - nickelpro 2y ago
    perf does not provide me with the complete callstack, it's a sampling profiler. In effectively all latency-sensitive contexts, sampling is worthless. 99.999999% of the time the program is waiting for IO, and then for a handful of microseconds there's a flurry of activity. That activity is the only part I care about and perf will effectively always miss it and never record it to completion. I need to know the exact chain of events that leads to an object cache miss causing an allocation to occur, or exactly the conditions which led to a slow path branch, or which request handler is consistently forcing buffer resizes, etc. I never need a profiler to tell me "memory allocation is slow" (which is what perf will give me). I know memory allocation is slow, I need to know why we're allocating memory.
cozzyd 2y ago
Lots of third party libraries have valgrind suppression files for false positivity.
rwmj 2y ago
I think they are complementary. Valgrind is especially useful because you don't need to recompile everything. In other words, you can test what you ship (albeit slowly), and that includes dependent libraries that may have their own bugs. On the other hand, ASAN is essential for fuzzing code.
kazinator 2y ago
Valgrind works on the same binary executable that you're be shipping, not some special build. Among the sanitizers the valuable ones are the general undefined behavior ones. Valgrind won't tell you about your integer overflows and whatnot. Like that in b >> a, a turned out to be 32 or greater at run-time.

synergy20 2y ago

same here, also for embedded systems valgrind is too heavy to run natively

lbrandy 2y ago

For uninitialized memory reads, which is one of the biggest classes of issues, valgrind can still be invaluable. MSAN is one of the more difficult things to get setup and remove all the false positives. You typically need to transitively compile everything including dependencies, or annotate/hint lots of things to get the signal-to-noise ratio right. Sometimes its just easier/better/faster to run it under valgrind.

patrick451 2y ago

IME, sanitizer don't find enough issues compared valgrind, and valgrind doesn't require me to recompile the world. If I have anything that feels like UB, especially that I can trigger in a unit test, I run it through valgrind first. If the issue can only be triggered by running the whole system and valgrind slows it down too much, there's a good chance that sanitizers will also slow it down too much.

nickelpro 2y ago

Callgrind is indispensable for performance profiling and has no compiler-based equivalents

Sesse__ 2y ago
Callgrind is certainly dispensable; just use a profiler. They are much, much faster, and more accurate as well. (Callgrind is using an idealized model of CPUs as they were around 1995, which doesn't match up all that well with how they work today.) There are some situations where I find myself using Callgrind, in particular in situations where stack traces are hard to extract using a regular profiler. But overall, it's a tool that I find vastly overused.
- dennis_moore 2y ago
  Which profilers in particular are you referring to because I've always thought that Callgrind is a profiler? perf?
  - rwmj 2y ago
    perf on the whole system, with the whole software stack compiled with stack pointers, flamegraphs for visualisation, is an essential starting point for understanding real world performance problems.
  - Sesse__ 2y ago
    perf or Intel VTune are the two standard choices AFAIK. Both have a certain learning curve, both are extremely capable in the right hands. (Well, on macOS you're pretty much locked to using Instruments; I don't know if Callgrind works there but would suspect it's an uphill battle.) Callgrind is a CPU simulator that can output a profile of that simulation. I guess it's semantics whether you want to call that a profiler or not, but my point is that you don't need a simulator+profiler combo when you can just use a profiler on its own. (There are exceptions where the determinism of Callgrind can be useful, like if you're trying to benchmark a really tiny change and are fine with the bias from the simulation diverging from reality, or if you explicitly care about call count instead of time spent.)
- nickelpro 2y ago
  perf does not provide me with the complete callstack, it's a sampling profiler. In effectively all latency-sensitive contexts, sampling is worthless. 99.999999% of the time the program is waiting for IO, and then for a handful of microseconds there's a flurry of activity. That activity is the only part I care about and perf will effectively always miss it and never record it to completion. I need to know the exact chain of events that leads to an object cache miss causing an allocation to occur, or exactly the conditions which led to a slow path branch, or which request handler is consistently forcing buffer resizes, etc. I never need a profiler to tell me "memory allocation is slow" (which is what perf will give me). I know memory allocation is slow, I need to know why we're allocating memory.

cozzyd 2y ago

Lots of third party libraries have valgrind suppression files for false positivity.

rwmj 2y ago

I think they are complementary. Valgrind is especially useful because you don't need to recompile everything. In other words, you can test what you ship (albeit slowly), and that includes dependent libraries that may have their own bugs. On the other hand, ASAN is essential for fuzzing code.

kazinator 2y ago

Valgrind works on the same binary executable that you're be shipping, not some special build. Among the sanitizers the valuable ones are the general undefined behavior ones. Valgrind won't tell you about your integer overflows and whatnot. Like that in b >> a, a turned out to be 32 or greater at run-time.