On Wed, 2014-02-05 at 18:17 -0500, Jeffrey Walton wrote: > On Wed, Feb 5, 2014 at 6:06 PM, Tom Hughes <t...@compton.nu> wrote: > > On 05/02/14 23:00, Jeffrey Walton wrote: > > > >> Well, I'm not sure how to proceed since RAND_init_fips is the linchpin. > >> > >> A call to ... -> RAND_init_fips -> ... -> fips_aes_encrypt is OK. > >> > >> A call to ... -> AES_encrypt -> ... -> fips_aes_encrypt is BAD. > >> > >> I'm fairly certain I need to include RAND_init_fips to rule out a > >> legitimate uninitialized read, but I'm not sure how to do it. > >> > >> Any ideas how to craft this rule? > > > > > > You can't. There is no way to write a suppression which says "don't worry > > about reads from the memory that was allocated at location X" which is what > > you are tryng to do. > Thanks Tom. That's not the answer I wanted :) > > Jeff Note that I believe we already had multiple requests to have suppression entries which could match the "two" stacktraces of a reported error, e.g. for the case you present, but also for the helgrind errors, which also typically have more two stacktraces.
So, you might enter an entry in bugzilla (with severy wish :) and hope someone is interested to work on that. Philippe ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
