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).

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:

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:

{
  <insert_a_suppression_name_here>
  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:

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.