Fixes for example: https://travis-ci.org/bitcoin/bitcoin/jobs/46093269 and https://travis-ci.org/bitcoin/bitcoin/jobs/46114383
on rare occasions, rand() was returning duped values, causing duplicate transactions.
BuildMerkleTree happily used these, but CPartialMerkleTree caught them and returned a null merkle root.
Rather than taking chances with rand(), use the loop counter to guarantee unique values.
At sipa's request, also remove the remaining uses of rand().
on rare occasions, rand() was returning duped values, causing duplicate
transactions.
BuildMerkleTree happily used these, but CPartialMerkleTree caught them and
returned a null merkle root.
Rather than taking changes with rand(), use the loop counter to guarantee
unique values.
At sipa's request, also remove the remaining uses of rand().
Switching from rand to insecure_rand prevents duplicates? How big is this random output exactly?
No, replacing the rand with deterministic, non-random variables prevents duplicates.
Oh, so the line in the 40s is the key change here. What's the difference between rand and insecure_rand, that the rest of the change switches to?
@michagogo insecure_rand is under our full control, which means it's possible to replay tests that failed (even on a different platform with different libc), at least if we log the seed value. It also removes all platform dependent variability in random values used for testing.
Ah. Makes sense. Thanks! Just looked and realized that insecure_rand is something that is actually defined by one of our own files. That added include should have clued me in sooner… (I'm assuming that rand is a built-in RNG?)
On Wednesday, January 7, 2015, Wladimir J. van der Laan < notifications@github.com> wrote:
@michagogo https://github.com/michagogo insecure_rand is under our full control, which means it's possible to replay tests that failed (even on a different platform with different libc), at least if we log the seed value.
— Reply to this email directly or view it on GitHub #5611 (comment).