id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
12258,Removing Valgrind Conditional Issues in seed_rng.hpp for Valgrind,deene.dafoe@…,Andy Tompkins,"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?
",Bugs,closed,Boost 1.66.0,uuid,Boost 1.61.0,Problem,worksforme,,