[reSIProcate] Valgrind complains with Resiprocate

[Adam Roach]

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 at nostrum.com] 
> 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
>