Is it possible to make valgrind ignore certain libraries?

Question

Or preferably all of them instead of just my code? My program uses Gtk, Loudmouth and few other things, and these two (and some behind them, libgcrypto, libssl) are causing

Answer 1

You can generate suppressions for the errors for the libraries, but I don't think you can exclude the libraries generally.

Also it's hard to automatically know if a memory error in the library is caused by a problem in your code or not.

Answer 2

With OpenSSL in particular, this is very hard. SSL encryption keys are partially based on uninitialized stack garbage, which means that all decrypted data is contaminated too. This contamination tends to spread beyond OpenSSL itself.

Compiling OpenSSL with a "PURIFY" option may help here. Unfortunately, due to some poorly thought out actions by a major Linux distribution, this is unlikely to become default.

A very blunt workaround is memcheck's --undef-value-errors=no option.

Answer 3

Assuming you are running the memcheck tool and you want to ignore Leak errors in libcrypto only, you could put a suppression like:

{
   ignore_libcrypto_conditional_jump_errors
   Memcheck:Leak
   ...
   obj:*/libcrypto.so.*
}

... into a file and pass it to valgrind with --suppressions=*FILENAME*.

To ignore Leak errors in all shared libraries under any lib directory (/lib, /lib64, /usr/lib, /usr/lib64, ...):

{
   ignore_unversioned_libs
   Memcheck:Leak
   ...
   obj:*/lib*/lib*.so
}
{
   ignore_versioned_libs
   Memcheck:Leak
   ...
   obj:*/lib*/lib*.so.*
}

It is unlikely, but you may need to add additional variations of the directory pattern to account for the locations of the X11 and GTK libraries.

Beware that this will ignore errors caused by any callbacks you wrote that were invoked by the libraries. Catching errors in those callbacks could almost be done with:

{
   ignore_unversioned_libs
   Memcheck:Leak
   obj:*/lib*/lib*.so
   ...
   obj:*/lib*/lib*.so
}
{
   ignore_versioned_libs
   Memcheck:Leak
   obj:*/lib*/lib*.so.*
   ...
   obj:*/lib*/lib*.so.*
}

... but this reveals errors in calls by a library that use the Valgrind malloc. Since valgrind malloc is injected directly into the program text -- not loaded as a dynamic library -- it appears in the stack the same way as your own code does. This allows Valgrind to track the allocations, but also makes it harder to do exactly what you have asked.

FYI: I am using valgrind 3.5.