Hacker News Reader

Comment by o11c | Hacker News Reader

One thing I've never understood regarding valgrind - other than intentional leaks, are suppression files ever actually used due to an actual false positive, or is it just due to the bug being in someone else's code that's annoying to fix?

"We implement our own memory allocator" is no excuse; the primitives you use should be hooked by valgrind so at most there should be false negatives due to your allocations being larger than the user-facing ones ...

View on HN

> are suppression files ever actually used due to an actual false positive,

There used to be one in LuaJIT because it had an optimized string comparison that compared outside of the allocation (which is allowed by the OS as long as you don't cross a page boundary, which LuaJIT's allocation algorithm made sure it never did)

The suppression was removed in https://github.com/LuaJIT/LuaJIT/commit/ff34b48ddd6f2b3bdd26... when the string hashing got a new implementation

First and foremost, suppressions can be used for more than leaks. For example, for "Conditional jump or move depends on uninitialised value(s)", which yes, there are very much false positives for because of e.g. tricky optimizations LLVM performs and that valgrind can't handle.

But even for leaks, you can also have intentional leaks that valgrind will flag but that you can't really do anything about. One example is how using `putenv` can lead to you having to leak memory on purpose. There are many other cases.

Yes, we use suppression files to cover expected leaks, as well as bugs in other code that is annoying to fix.

For example the OCaml suppressions here are because OCaml (as expected) doesn't free static allocations at program exit. You can also see some real bugs we found:

https://gitlab.com/nbdkit/nbdkit/-/tree/master/valgrind?ref_...

Reply on news.ycombinator.com