FWIW I consider the suppression file to be non-useful:
- You have to remember a complex manual syntax to use it, passing the path to each desired suppression file on the command line.
- It doesn’t scale. Even if GLib and GTK maintain suppression files, they’re hardly the only libraries in our stack. We’d need more files for pango, fontconfig, etc. etc. etc. All must be manually specified with a long command line.
- It doesn’t work at all for asan, which is equally important.
I never use it.
The first two of those points could be fixed if valgrind were to support a standard suppressions directory that would be used automatically rather than manually, similar to how GLib’s gdb python extensions require zero effort to use. I bet 95% of our gdb extension users don’t even realize it exists. That would be a big step forward. But even that would do no good for asan, which is, again, just as important.
Normally it is not too hard to avoid leak complaints from valgrind. If you need a one-time “leak” of an object that should be valid for the duration of the program, you can keep a pointer to it in a static variable, then valgrind should not complain. GLib runs into trouble when it either doesn’t use a static variable to store the pointer, or keeps tricky pointers at offsets to the real allocated region.