Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#12258 closed Bugs (worksforme)

Removing Valgrind Conditional Issues in seed_rng.hpp for Valgrind

Reported by: deene.dafoe@… Owned by: Andy Tompkins
Milestone: Boost 1.66.0 Component: uuid
Version: Boost 1.61.0 Severity: Problem
Keywords: Cc:

Description

There are a handful of tickets already created relating to the use of uninitialized memory in the boost::uuids::random_generator code.

e.g. 9407 (patch) 7248 (bug) 4002 (closed, documentation).

The concerns seem to be two fold. Some folks are concerned with the correctness of using uninitialized memory as a source of randomness/entropy, and generally with the noise caused by Valgrind.

4002 attempts to 'fix' the latter by adding documentation stating to add Valgrind suppressions. Unfortunately, using Valgrind Suppressions is not always useful if one thread generates the UUID and another thread uses it. In this case the thread that generates the Valgrind Issue does not include the boost code of interest (in the stack) so a suppression is needed for EACH instance.

I'm seeing 100s if not 1000s of this scenario in a Valgrind Application I'm running and we finally gave up creating individual suppressions by patching the boost code to not use uninitialized memory when being compiled in a build meant to be used on Valgrind. We do not change the Boost code when doing any other build type other than for one intended to run only on Valgrind.

If there is no plan to remove the uninitialized memory from the production code, is it possible to at least update the code to have some sort of Valgrind compile time flag so when built with this Valgrind flag the Valgrind Issues can be suppressed at the source?

Change History (4)

comment:1 by Michel Morin, 6 years ago

Component: Noneuuid
Owner: set to Andy Tompkins

comment:2 by James E. King, III <jking@…>, 5 years ago

I ran valgrind on test_random_generator and there were no warnings or errors, even after I reinstated the commented-out test for boost::random::random_device. I confirmed in the debugger that we're going through seed_rng, specifically the purposefully uninitialized array (in the case I saw, it was not done for entropy, but instead for performance). Do you still believe there is an issue here? I did not use any suppressions. Sample code demonstrating the issue would also be helpful here. Thanks.

comment:3 by James E. King, III, 5 years ago

Resolution: worksforme
Status: newclosed

I am unable to reproduce the issues with the latest development tip. See:

https://svn.boost.org/trac10/ticket/7248 https://svn.boost.org/trac10/ticket/9407

comment:4 by James E. King, III, 5 years ago

Milestone: To Be DeterminedBoost 1.66.0
Type: TasksBugs
Note: See TracTickets for help on using tickets.