8215759: java/math/BigInteger/ModPow.java can throw an ArithmeticException
Brian Burkhalter
brian.burkhalter at oracle.com
Fri Dec 21 16:22:00 UTC 2018
Hi Peter,
> On Dec 21, 2018, at 8:15 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
> This is really highly unlikely (1 in 2^800). In fact, it was not possible for this particular test to produce zero BigInteger. That's because the test uses a pseudo-random generator with deterministic algorithm and it uses a constant seed to initialize it before generating the next 2000 BigInteger random numbers with magnitude 0 ... 2^800 - 1:
>
> 33 Random rnd = new Random(1234);
> 34
> 35 for (int i=0; i<2000; i++) {
> 36 BigInteger m = new BigInteger(800, rnd);
>
> So if this test didn't fail with zero BigInteger when it is was run for the 1st time, then it can't fail in any other run, because the random numbers produced are the same in any run.
You might be correct for numBits == 800, but if one changes 800 to 8 it fails the first time.
> But for the sake of correctness, let's pretend that the numbers are really random. Why pretend? Why not make them really random? By using SecureRandom instead with really random seed?
>
> Is it important for such test to be deterministic? Perhaps, so it can be re-executed with repeatable results in case it fails.
>
> So the middle ground would be to make the test undeterministic, but repeatable. By calculating a really random seed (using SecureRandom) and use that seed in a known deterministic pseudo-random generator (java.util.Random) while printing the used seed to the output log before executing the the test logic. In case the test fails, it can be repeated by providing the seed from the log of the failed execution...
>
> Just thinking loud. Not suggesting you really do anything like that to this test…
Probably you are correct however about the randomness. It should be changed to use RandomFactory.
Thanks,
Brian
More information about the core-libs-dev
mailing list