How do you tell Valgrind to completely suppress a particular .so file?

后端 未结 3 1217
野趣味
野趣味 2020-12-05 02:32

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 tel

相关标签:
3条回答
  • 2020-12-05 03:02

    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
       ...
    }
    
    0 讨论(0)
  • 2020-12-05 03:08

    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.

    0 讨论(0)
  • 2020-12-05 03:12

    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
       ...
    }
    
    0 讨论(0)
提交回复
热议问题