Re: [reSIProcate] Valgrind complains with Resiprocate
Mystery solved, then. The warnings you describe are perfectly harmless,
and you can suppress them in valgrind. Alternately, if you don't want to
do that, you can re-compile the OpenSSL library with the -DPURIFY
option, which ensures that the buffers used to generate random data are
initialized (albeit with a very slight performance penalty).
/a
Aron Rosenberg wrote:
Yes, we do have the regular linux calls shunted to OpenSSL since it
fixed a very strange MultiCore issue we were having with duplicated
random values (see the mailing list from last month).
-Aron
-----Original Message-----
From: Adam Roach [mailto:adam@xxxxxxxxxxx]
Sent: Friday, May 02, 2008 10:52 PM
To: Byron Campen
Cc: Aron Rosenberg; resiprocate-devel
Subject: Re: [reSIProcate] Valgrind complains with Resiprocate
Byron Campen wrote:
Yeah, I have seen this too, and I haven't had time to get to the
bottom of it. Anyone else?
I can't reproduce with anything that uses getRandomHex() in the current
tree on my system. I *was* able to reproduce and track down the problem
using getCryptoRandomHex(). It turns out that many pseudo-random number
generators don't bother with initializing the buffers they start
permuting to produce random numbers. Consequently, you can end up with
valgrind complaining about use of uninitialized values whenever you
start using these random numbers for certain purposes (such as indexing
arrays or making branch decisions). It's a real pain to track down, too,
since valgrind doesn't point out when you assign uninitialized values
(or perform other operations with them, such as simple math) -- it
simply marks the result of these copies as uninitialized also.
However, it looks like the normal linux pseudo-random number generator
doesn't have this property. So, to eliminate what I think is the most
probable suspect, I have to ask Aron: have you made any modifications to
the Random class that either use an alternate PRNG, or shunt over to
OpenSSL for calls to getRandom()?
/a