How do you tell Valgrind to completely suppress a

Question

I'm trying to use Valgrind on a program that I'm working on, but Valgrind generates a bunch of errors for one of the libraries that I'm using. I'd like to be able to tell it to suppress all errors which involve that library. The closest rule that I can come up with for the suppression file is

{
   rule name
   Memcheck:Cond
   ...
   obj:/path/to/library/thelibrary.so
}

This doesn't entirely do the job, however. I have to create one of these for every suppression type that comes up (Cond, Value4, Param, etc), and it seems to still miss some errors which have the library in the stack trace.

Is there a way to give Valgrind a single suppression rule to make it completely ignore a particular library? And even if there is no way to make such a rule which covers all suppression types, is there at least a way to create a rule which ignores all errors of a particular suppression type from a particular library?

Answer 1

For most of the suppression types, you omit the wildcard, like so:

{
   name
   Memcheck:Cond
   obj:/path/to/lib/lib.so.10.1
}

{
   name
   Memcheck:Free
   obj:/path/to/lib/lib.so.10.1
}

{
   name
   Memcheck:Value8
   obj:/path/to/lib/lib.so.10.1
}

Note that you must list each type of error separately, you can't wildcard them. You must also list the entire pathname of the library (as shown by valgrind, with any "decorations" like version numbers).

Also, leaks are handled differently -- for those you need something that looks like this:

{
   name
   Memcheck:Leak
   fun:*alloc
   ...
   obj:/path/to/lib/lib.so.10.1
   ...
}

Answer 2

It appears that it is necessary to include a separate suppression record for each type of error (Cond, Value4, Param, etc). But based on my testing with valgrind-3.6.0.SVN-Debian, I believe you can use the following simplified form for each type of error...

{
   <insert_a_suppression_name_here>
   Memcheck:Cond
   ...
   obj:/path/to/library/thelibrary.so.*
   ...
}

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   ...
   obj:/path/to/library/thelibrary.so.*
   ...
}

The three dots are called frame-level wildcards in the Valgrind docs. These match zero or more frames in the call stack. In other words, you use these when it doesn't matter who called into the library, or what functions the library subsequently calls.

Sometimes errors include "obj:" frames and sometimes they only use "fun:" frames. This is based, in general, on whether or not that function is included in the library's symbol table. If the goal is to exclude the entire library, it may work best if the library does not include symbols so that you can exclude based on the library filename instead of having to create separate suppressions for each function call within the library. Hopefully, Valgrind is clever enough to suppress errors based on library filename even when it does know the function name, but I haven't verified this.

If you do need to add suppressions based on individual functions within the library, you should be able to use the same form...

{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   ...
   fun:the_name_of_the_function
   ...
}

Note: You can include --gen-suppressions=all on the valgrind command-line in order to see the exact form and names (including any C++ mangling) required to suppress each error. You can use that output as a template for your suppression records -- in which you would usually want to replace most lines with ... in order to simplify the process of suppressing all errors that might occur in association with a specific library or function call.

Note: <insert_a_suppression_name_here> is a placeholder in which you can type whatever descriptive text that you want. It is required to not be blank.

Answer 3

nobar's answer almost worked for me, but I was getting a syntax error:

==15566== FATAL: in suppressions file "suppresion.error.txt" near line 4:
==15566==    bad or missing extra suppression info
==15566== exiting now.

For system calls, I needed to add an extra line as the docs state:

Param errors have a mandatory extra information line at this point,
which is the name of the offending system call parameter.

So I ended up with this and it worked:

{
   <sup_mmap_length>
   Memcheck:Param
   mmap(length)
   ...
   fun:function_from_offending_lib
   ...
}