# Valgrind Suppressions **Suppression files** tell Valgrind to ignore specific errors from system libraries, language runtimes, or trusted third-party code. They're necessary to reduce noise from false positives that you can't fix (e.g., intentional optimizations in libc that Valgrind can't understand). ```bash valgrind --suppressions=my.supp ./program ``` A suppression file contains patterns matching error locations and types. When Valgrind encounters an error, it checks the suppression file. If the error matches a suppression, it's silently ignored. **Generating suppressions:** ```bash valgrind --gen-suppressions=yes ./program 2>&1 | tee valgrind.log ``` With `--gen-suppressions=yes`, Valgrind prints a suppression template after each error. You can copy these into a suppression file and customize them. **Example suppression:** ``` { Memcheck:Leak match-leak-kinds: reachable fun:malloc fun:setup_library obj:/usr/lib/libfoo.so } ``` Each suppression has: 1. A name (for reference) 2. Tool and error type (Memcheck:Leak, Memcheck:BadFree, etc.) 3. Leak kind filter (optional, for Leak errors) 4. A pattern matching the error's stack trace `fun:` matches a function name, `obj:` matches a binary/library file, `*` is a wildcard. **Common suppression patterns:** ``` # Suppress all leaks in libc { libc_leaks Memcheck:Leak ... obj:/lib/libc-*.so } # Suppress a specific false positive { my_benign_race DRD:ConflictingAccess fun:my_function fun:caller } # Suppress still-reachable leaks at exit { exit_leaks Memcheck:Leak match-leak-kinds: reachable ... } ``` **Distribution suppressions:** Most distros ship default suppression files for common false positives. Check for them: ```bash ls /usr/lib/valgrind/*.supp # system suppressions valgrind --leak-check=full ./program 2>&1 | grep -i "suppression" ``` These defaults suppress known false positives from glibc, libstdc++, and other core libraries. **Best practices:** 1. Start without suppressions—address real bugs first 2. Use `--gen-suppressions=yes` to generate templates 3. Review generated suppressions carefully—verify they're false positives, not bugs 4. Keep suppressions minimal—only suppress what you can't fix 5. Document why each suppression exists (comment in the file) Too many suppressions hide real bugs. If a suppression file grows large, investigate whether underlying code needs fixing instead. **Suppression conflicts:** If two suppression files conflict (both match but one suppresses and one doesn't), load them in the right order. More specific suppressions should come first.