| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
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