19

Valgrind will tell you the origin of the uninitialized values with the track-origins=yes option.

I tried to suppress these warnings but the problem is that data based on uninitialized values can propagate everywhere, causing warnings elsewhere too.

The solution would be suppressing by the origin of the uninitialized data. How can I do it? Is it possible? It seems suppress files only filter the stack trace only.

The reason I want this, that OpenSSL enhances randomness by using uninitialized values on purpose, and I want to test a release build with valgrind (so -DPURIFY is not an option).

Calmarius
  • 18,570
  • 18
  • 110
  • 157
  • I'm looking for the exact same, but I suspect this is not something that Valgrind supports, nor is likely to support. Such a suppression would only work with `track-origins=yes`; without it the suppression would be useless. I'd be happy to be proved wrong though! – Jon Gjengset Nov 25 '13 at 15:13

3 Answers3

11

My initial read of your question is that you might be okay with disabling all uninitialized value errors, in which case --undef-value-errors=no would do the trick.

If you're looking for something piecemeal, some hasty testing seems to indicate using --gen-suppressions=yes, then answering y for the relevant outputs and dropping them in a suppressions file worked for me when fiddling with my openssl binary.

Also, you might find the answer to How do you tell Valgrind to completely suppress a particular .so file? useful.

Community
  • 1
  • 1
Arthur Shipkowski
  • 3,606
  • 1
  • 22
  • 30
  • 8
    No don't want to suppress uninitialized values, since such errors can be in my program... I want valgrind not to show error, when uninitialized value comes from a particular function. – Calmarius Aug 23 '13 at 09:45
3

The solution would be suppressing by the origin of the uninitialized data. How can I do it? Is it possible? It seems suppress files only filter the stack trace only.

I had the same problem with OpenSSL. According to Tom Hughes on the Valgrind mailing list, its not possible. See Frame-level wildcard not matching in suppression rule?.

In my case, I was trying to use frame level wildcards to suppress findings on the memory touched by RAND_init_fips (the OpenSSL FIPS version of the problem). This does not work, though we would like it to work:

{
   RAND_init_fips_1
   Memcheck:Cond
   ...
   fun:RAND_init_fips
   ...
}

{
   RAND_init_fips_2
   Memcheck:Value8
   ...
   fun:RAND_init_fips
   ...
}

{
   RAND_init_fips_3
   Memcheck:Value4
   ...
   fun:RAND_init_fips
   ...
}
jww
  • 97,681
  • 90
  • 411
  • 885
0

Try to add this to the suppresion file.

{
   cond
   Memcheck:Cond
   ...
   fun:*
   ...
}
{
   value8
   Memcheck:Value8
   ...
   fun:*
   ...
}

{
   value4
   Memcheck:Value4
   ...
   fun:*
   ...
}

For example, if your executable is a.out, create ./val.supp file with the content and run valgrind --suppressions=./val.supp ./a.out.

Přemysl Šťastný
  • 1,676
  • 2
  • 18
  • 39