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 so many errors themselves that I'm unable to detect my own. Is it possible to make valgrind ignore things coming from deeper than my own code?

Clubhaul

+1, I'm having the same troubles. NVIDIA's GL library does conditional jumps based on uninitialized memory, and std::string keeps throwing false positives ("possibly lost") as well. – Eastwardly

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.

Pinxit

valgrind.org/docs/manual/manual-core.html#manual-core.suppress This is the link for information on error suppression for valgrind. – Demavend

Answer 2

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.

Alejandrinaalejandro

The only thing missing with this answer is what to do with there suppression texts... – Lying

These settings are meant to be saved into suppressions file which is read when Valgrind starts up. Option --suppressions=<filename> See valgrind.org/docs/manual/manual-core.html – Glasgow

somewhat related... https://mcmap.net/q/302699/-can-i-make-valgrind-ignore-glibc-libraries. the link talks about how to use memcheck to generate all suppressions to a logfile. the logfile can then be used to create wildcard suppression expressions. – Aguayo

Answer 3

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.

Stadia

Nice. Ignoring undef-values actually made my particular case, where I had "More than 10000000 total errors detected" coming from a library (not OpenSSL), go through analysing the rest of the code. – Simplicidentate